On Tue, 4 Oct 2016, Andreas Krebbel wrote: > > (b) Handling EXCESS_PRECISION_TYPE_IMPLICIT like > > EXCESS_PRECISION_TYPE_FAST would accurately describe what the back end > > does. It would mean that the default FLT_EVAL_METHOD is 0, which is a > > more accurate description of how the compiler actually behaves, and would > > avoid the suboptimal code in libgcc and glibc. It would however mean that > > unless -fexcess-precision=standard is used, FLT_EVAL_METHOD (accurate) is > > out of synx with float_t in math.h (inaccurate). > > With (b) we would violate the C standard which explicitly states that > the definition of float_t needs to be float if FLT_EVAL_METHOD is 0. > I've no idea how much code really relies on that. So far I only know > about the Plum Hall testsuite ;) So this probably would still be a safe > change. Actually it was like that for many years without any problems > ... until I've changed it due to the Plum Hall finding :( > https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01124.html
You'd only violate it outside standards conformance modes (which you should be using for running conformance testsuites); with -std=c11 etc. -fexcess-precision=standard would be implied, meaning FLT_EVAL_METHOD remains as 1 in that case. -- Joseph S. Myers jos...@codesourcery.com
