[PATCH] D134859: [clang][Interp] Implement basic support for floating point values

Timm Bäder via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Dec 1 05:58:19 PST 2022


tbaeder added inline comments.


================
Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:152
+  case CK_FloatingToIntegral: {
+    llvm::RoundingMode RM = getRoundingMode(CE);
+    Optional<PrimType> ToT = classify(CE->getType());
----------------
sepavloff wrote:
> tbaeder wrote:
> > sepavloff wrote:
> > > According to C standard (6.3.1.4p1):
> > > ```
> > >     When a finite value of real floating type is converted to an integer type other than _Bool, the fractional part is discarded (i.e., the value is truncated toward zero).
> > > ```
> > > So the conversion should not depend on rounding mode. The same applies to the conversion to boolean (6.3.1.2p1):
> > > ```
> > >     When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.
> > > ```
> > > 
> > So this is a difference between C and C++?
> No, C++ behaves similarly ([conv.fpint]):
> ```
> A prvalue of a floating-point type can be converted to a prvalue of an integer type. The conversion truncates;
> that is, the fractional part is discarded.
> ```
> and [conv.bool]:
> ```
> A prvalue of arithmetic, unscoped enumeration, pointer, or pointer-to-member type can be converted to a
> prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false;
> any other value is converted to true.
> ```
> Theses conversions do not depend on rounding mode.
> 
> 
Ah ok, thanks for the explanation. That explains why the current interpeter hardcodes `rmTowardZero` there. The rounding mode in `Floating::convertToInteger` was unused for that reason.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134859/new/

https://reviews.llvm.org/D134859



More information about the cfe-commits mailing list