[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #24 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #23) > IMHO -fexcess-precision=16 (at least on x86_64 64-bit and with -mfpmath=sse > -msse2 32-bit too) are completely conformant modes, If this is the intent, it

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #23 from Jakub Jelinek --- IMHO -fexcess-precision=16 (at least on x86_64 64-bit and with -mfpmath=sse -msse2 32-bit too) are completely conformant modes, it is like 0 (where all of float, _Float32, double, _Float64, long double, _Fl

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #22 from Vincent Lefèvre --- (In reply to Vincent Lefèvre from comment #21) > What C23 documents applies *only* when -fexcess-precision=standard, as this > is the only -fexcess-precision value for which GCC is documented to be > conf

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #21 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #20) > C23 documents it in detail, and so does float.h: [...] > So, only __FLT_EVAL_METHOD_TS_18661_3__ should be possibly 16 for > -fexcess-precision=16. What C23

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #20 from Jakub Jelinek --- C23 documents it in detail, and so does float.h: /* The floating-point expression evaluation method. The precise definitions of these values are generalised to include support for the interchange and

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #19 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #18) > (In reply to Vincent Lefèvre from comment #17) > > 2 is more accurate. Note that -1 would not make GCC conforming with > > -fexcess-precision=fast. > > -fex

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #17 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #16) > 2 is of course the right value for -fexcess-precision=standard -m32 on x86 So, it is not meant to affect __FLT_EVAL_METHOD__. FYI, -fexcess-precision has be

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #18 from Jakub Jelinek --- (In reply to Vincent Lefèvre from comment #17) > > (for -fexcess-precision=fast arguably it should be IMHO -1). > > 2 is more accurate. Note that -1 would not make GCC conforming with > -fexcess-precision=

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #16 from Jakub Jelinek --- 2 is of course the right value for -fexcess-precision=standard -m32 on x86 (for -fexcess-precision=fast arguably it should be IMHO -1). Anyway, if you don't believe -fexcess-precision= affects the FLT_EVAL

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #15 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #14) > (In reply to Vincent Lefèvre from comment #13) > > -fexcess-precision is not meant to have an effect on __FLT_EVAL_METHOD__, > > No, -fexcess-precision= is

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #14 from Jakub Jelinek --- (In reply to Vincent Lefèvre from comment #13) > -fexcess-precision is not meant to have an effect on __FLT_EVAL_METHOD__, No, -fexcess-precision= is meant to have an effect on __FLT_EVAL_METHOD__, it is w

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-04-11 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #13 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #7) > Though, I think we should predefine __FLT_EVAL_METHOD__ to 16 rather than 0 > for -fexcess-precision=16. -fexcess-precision is not meant to have an effect on

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-26 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #12 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #9) > The reason for extended precision by default for _Float16 (and __bf16) on > x86 (and most of other targets, I think RISC-V is an exception) is lack of > hw su

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #11 from Richard Biener --- A default that's different depending on target is also a recipie for problems.

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #10 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #9) > The reason for extended precision by default for _Float16 (and __bf16) on > x86 (and most of other targets, I think RISC-V is an exception) is lack of > hw supp

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-26 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #9 from Jakub Jelinek --- The reason for extended precision by default for _Float16 (and __bf16) on x86 (and most of other targets, I think RISC-V is an exception) is lack of hw support, same reason as for i387 extended precision. Ei

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-25 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #8 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #6) > I don't think that is true. Indeed, it seems that I did some mistake when searching the standard, which is a bit contradictory about the case FLT_EVAL_METHOD

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #7 from Jakub Jelinek --- Though, I think we should predefine __FLT_EVAL_METHOD__ to 16 rather than 0 for -fexcess-precision=16.

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #6 from Jakub Jelinek --- (In reply to Vincent Lefèvre from comment #5) > (In reply to Jakub Jelinek from comment #2) > > That is the normal behavior of extended precision. > > If you think of FLT_EVAL_METHOD, then this applies *onl

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-25 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Com

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-25 Thread stefansf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #4 from Stefan Schulze Frielinghaus --- Thanks for pointing this out. I was fearing that this is valid but wasn't sure. Especially the difference between (_Float16) 42.42f16 and just the constant without the cast, I didn't have on

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2

[Bug c/119014] Extending _Float16 constant at compile and run time differs

2025-02-25 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 Richard Biener changed: What|Removed |Added Target||x86_64-*-* CC|