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
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
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
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
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
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
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
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=
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
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
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
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
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
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.
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
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
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
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.
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
CC|
24 matches
Mail list logo