Following code produces wrong results: #include <stdio.h> float f = -1.0f ; int main( void ) { if ( (unsigned int)f != (unsigned int)-1.0f ) { printf( "%-12s %04d:NG...[%u]--->[%u]\n", __FILE__, __LINE__, (unsigned int)-1.0f, (unsigned int)f ) ; } else { printf( "[%u]--->[%u] :OK\n", (unsigned int)-1.0f, (unsigned int)f ) ; } return( 0 ) ; } [dinar@dinar tmp]$ /home/dinar/work/gcc-builds/gnu/gcc-i686-pc-linux-gnu/bin/gcc sample.c -o sample [dinar@dinar tmp]$ ./sample sample.c 0010:NG...[0]--->[4294967295] [dinar@dinar tmp]$ /home/dinar/work/gcc-builds/gnu/gcc-i686-pc-linux-gnu/bin/gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/home/dinar/work/gcc-builds/gnu/gcc-i686-pc-linux-gnu/ --enable-languages=c,c++ Thread model: posix gcc version 4.1.0 20050429 (experimental)
Created attachment 8806 [details] testcase
Created attachment 8807 [details] proposed patch
Confirmed.
Conversion of out-of-range floating point values to integers yields undefined behavior in both C and C++. There is no need for it to be consistent between compile-time and runtime conversions. However, the ISO C decimal floating point proposals (DTR 24732 / WG14 N1107) make it well-defined for binary as well as decimal floating-point types. So we do want to support well-defined semantics (namely, those in that proposal) for both compile-time and runtime conversions, at least under a command-line option to enable them. I don't know whether dfp-branch has such support yet. Performance measurements would be needed to ascertain whether there is any benefit to having both versions or whether we might as well just always use the DTR 24732 semantics for these conversions (and document that we are doing so, and seek out and eliminate any optimizations in the compiler which depend on such conversions being undefined - a search for such optimizations being a necessary part of the decimal floating point work anyway if not already done).
Created attachment 8816 [details] propesed patch
To the extent this is a bug, it's a failure to comply to a future standard. As such, it's certainly not release-critical, and it's not even really a regression. Removed target milestone and regression markers.
It's come to my attention that C99 Annex F.4#1 specifies that the result is an unspecified value, with the "invalid" exception raised at runtime, rather than undefined behavior (in the absence of defining __STDC_IEC_559__, it's still undefined behavior). We don't currently implement FENV_ACCESS at all so the exception is irrelevant and I don't think we currently have any optimizations relying on the conversion being undefined rather than unspecified, but in any case the decimal fp work will answer the questions of what optimizations we do here and whether there is any performance cost to defining the results the way the decimal fp proposals do unconditionally.
6.3.1.4/1 says this is undefined.