[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 Andrew Pinski changed: What|Removed |Added CC||gnu.ojxq8 at dralias dot com --- Comment #13 from Andrew Pinski --- *** Bug 114740 has been marked as a duplicate of this bug. ***
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 Andrew Pinski changed: What|Removed |Added CC||sjh at schilling dot dk --- Comment #12 from Andrew Pinski --- *** Bug 114050 has been marked as a duplicate of this bug. ***
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Andrew Pinski --- Invalid as explained
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #10 from joseph at codesourcery dot com --- This has nothing to do with 84717. The present bug is simply invalid; GCC is acting as specified in the C standard for excess precision. 84717 is arguably a legitimate issue about lack of documentation for an extension (albeit an extension taken from an old TR).
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84717 --- Comment #9 from Eric Gallager --- due to the part about floating/double constant suffixes, I think bug 84717 is related
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #8 from Vincent Lefèvre --- (In reply to and...@wahrzeichnen.de from comment #6) > 6.6 (5) "An expression that evaluates to a constant is required in several > contexts. If a floating expression is evaluated in the translation > environment, the arithmetic range and precision shall be at least as great > as if the expression were being evaluated in the execution environment. > --footnote: The use of evaluation formats as characterized by > FLT_EVAL_METHOD also applies to evaluation in the translation environment." This is about constant expressions and is not applicable to constants. See 5.2.4.2.2p9 for constants.
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #7 from Vincent Lefèvre --- (In reply to jos...@codesourcery.com from comment #5) > Lack of direct float and double arithmetic requires FLT_EVAL_METHOD == 2 No, FLT_EVAL_METHOD could also be negative, in which case GCC would be allowed to evaluate floating-point constants of type float in whatever range and precision it wishes.
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #6 from anders at wahrzeichnen dot de --- (In reply to jos...@codesourcery.com from comment #3) > This is as specified in the C standard. I guess you are referring to the C18 section 6.3.1.8 (2) "The values of floating operands and of the results of floating expressions may be represented in greater range and precision than that required by the type; the types are not changed thereby. --footnote: The cast and assignment operators are still required to remove extra range and precision." in conjunction with 6.6 (5) "An expression that evaluates to a constant is required in several contexts. If a floating expression is evaluated in the translation environment, the arithmetic range and precision shall be at least as great as if the expression were being evaluated in the execution environment. --footnote: The use of evaluation formats as characterized by FLT_EVAL_METHOD also applies to evaluation in the translation environment." If so, I propose to close this bug (as __FLT_EVAL_METHOD__ is indeed 2).
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #5 from joseph at codesourcery dot com --- Most architectures use FLT_EVAL_METHOD == 0. It's specific to x87 (and older m68k) that FLT_EVAL_METHOD == 2 because x87 doesn't support direct arithmetic on float or double. Lack of direct float and double arithmetic requires FLT_EVAL_METHOD == 2 and FLT_EVAL_METHOD == 2 requires interpreting floating constants to the range and precision of long double, whatever their semantic type.
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #4 from anders at wahrzeichnen dot de --- I don't know about other archs, but on amd64, GCC emits comiss insns (SSE2 single-precision scalar compare) for f0, f1, and f2 and comisd insns (SSE2 double-precision scalar compare) for f3. So this is evidently not a problem on amd64 (i.e. it does not depend on how the decimal-to-binary rounding was done for the value 0.1). Conclusion: Ignoring the 'f' suffix seems to be specific for 387.
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #3 from joseph at codesourcery dot com --- The value of FLT_EVAL_METHOD applies to constants as well as to operations. That is, when FLT_EVAL_METHOD == 2, 0.1f has the precision of long double but the semantic type of float, and 0.1 has the precision of long double but the semantic type of double. An explicit cast to float removes excess precision. This is as specified in the C standard.
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #2 from anders at wahrzeichnen dot de --- No, -ffloat-store does not help. And this has little if anything to do with 323, imho. The asm generated for f3 is instructive: There, GCC wants to load a double constant 0x3fba into the 387 FPU, which is 0.1555... The single-precision constant t passed as argument to f0...f3 is 0x3dcd, which is 0.1000149... So, it's no wonder that f3 returns 1; after all 0.1000149 > 0.1555. The questions are: Why does the code generated for f2 try to load a double constant even if it is explicitly suffixed 'f'? Why should casting to (float) help? Why does std=c11 or c18 change the game?
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 Andrew Pinski changed: What|Removed |Added Target||i?86-linux-gnu Depends on||323 --- Comment #1 from Andrew Pinski --- Does -ffloat-store help? See 323 also. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 [Bug 323] optimized code gives strange floating point results
