https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #19 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- (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. > > -fexcess-precision=fast is not standard conforming, that is why > -fexcess-precision=standard has been introduced (and made default for > -std=c* modes). And on x86 -m32 in that mode not everything is using long > double precision, it is pretty much about luck whether something can stay in > the 387 stack registers (then it is using long double excess precision) or > needs to be spilled out (then it has float/double/_Float16 precision). > And constants aren't using excess precision. > FLT_EVAL_METHOD -1 means that it is indeterminable. If constants aren't using excess precision with -fexcess-precision=fast (but this is not what is documented), then perhaps that FLT_EVAL_METHOD should be -1. But anyway, taking FLT_EVAL_METHOD into account does not make much sense since GCC is not conforming with -fexcess-precision=fast (according to the C standard, even if FLT_EVAL_METHOD is -1, values after an assignment or a cast are not expected to have any excess precision, so any value of FLT_EVAL_METHOD is misleading). > > > Anyway, if you don't believe -fexcess-precision= affects the > > > FLT_EVAL_METHOD > > > values, just look at the source: > > > > Then this is a bug. > > No. The issue is that if -fexcess-precision=16 (which affects *only* _Float16 and __bf16, as documented), this does not give any information of what happens for float and double: there is not way to set it to *both* 16 and standard at the same time. This is really poor design.
