On Tue, 25 Jul 2017, Richard Biener wrote: > > 2) fold-const.c: > > > > 1882 /* The following code implements the floating point to integer > > 1883 conversion rules required by the Java Language Specification, > > 1884 that IEEE NaNs are mapped to zero and values that overflow > > 1885 the target precision saturate, i.e. values greater than > > 1886 INT_MAX are mapped to INT_MAX, and values less than INT_MIN > > 1887 are mapped to INT_MIN. These semantics are allowed by the > > 1888 C and C++ standards that simply state that the behavior of > > 1889 FP-to-integer conversion is unspecified upon overflow. */ > > 1890 > > 1891 wide_int val; > > 1892 REAL_VALUE_TYPE r; > > 1893 REAL_VALUE_TYPE x = TREE_REAL_CST (arg1); > > > > Can we somehow remove that Richi? > > Remove what? The comment? It still matches the code and we have to > do sth. So I don't see why we should change this. > > Maybe Joseph knows whether future standards / TRs recommend sth different > or exactly this.
The requirement under Annex F is to return an unspecified value (with "invalid" raised) for such overflowing / NaN conversions to integer. "unspecified value" means that any particular execution of the code must behave as if some consistent value was chosen; after double d; int i = d; you can't have one subsequent conditional show i == 0 and another show i == INT_MAX. But it's fine for different executions of that code to use different values. -- Joseph S. Myers jos...@codesourcery.com
