https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
Bug ID: 92875 Summary: GCC ignores the floating-point 'f' suffix in C11 mode Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: anders at wahrzeichnen dot de Target Milestone: --- Created attachment 47454 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47454&action=edit test case with return value 0 or 8 expected, returns 12 GCC treats floating-point constants suffixed with 'f' as double, when compiled with either -std=c11 or -std=c18. The attached test case illustrates this problem: There are four functions f0, f1, f2, and f3. The first three functions f0, f1, and f2 should all compile to the same code, f4 is different and there for reference. It turns out that with -std=387 and -m32 (or with -mfpmath=387), GCC compiles f0 and f1 to equivalent asm but not f2. Instead, it creates the same asm for f2 as for f3, involving some loading a constant into an FPU register using double precision. Apparently, writing '0.1f' is not enough to convince GCC that the constant is single precision. This can be seen with the attached program: $ gcc -O -m32 testcase.c && ./a.out; echo $? 8 $ gcc -std=c11 -O -m32 testcase.c && ./a.out; echo $? 12 The result should be either 0, 8, or 15, depending on how exactly the decimal constant 0.1 is rounded to binary floating-point, but it should never be anything else. The bug seems to be independent of optimization; it happens with -O0, -O1, -O2, -O3, -Os, and -Og. I can trace it from GCC 9.2 all the way back to 4.8.4. It can be triggered on 387 (with -m32 or -mfpmath=387).