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).
