Re: [4.5 C] C99-conforming excess precision (fix PR 323 for C)

["Joseph S. Myers" <joseph@codesourcery.com>]

On Wed, 5 Nov 2008, Ian Lance Taylor wrote:

> "Joseph S. Myers" <joseph@codesourcery.com> writes:
> 
> > Bootstrapped with no regressions on i686-pc-linux-gnu.  Are the
> > non-C-front-end parts OK for 4.5?
> 
> This is OK for 4.5.

(Note that this is built on the infrastructure from my constant 
expressions patch 
<http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01061.html>, which has 
changes to builtins.c and cp/typeck.c pending review for 4.5.)

> What happens if -fexcess-precision=standard is used with C++?  It
> seems that the option will be accepted without complaint but that
> there may be some cases where it will not work correctly.  It might be
> better to reject the option until the C++ frontend can be corrected.

Yes, the option is quietly ignored for

* languages whose front ends do not implement it (i.e. implement some form 
of predictable semantics for the option that mean GIMPLE arithmetic is not 
generated for types the back end does not support arithmetic on);

* processors with no excess precision issues, and processor configurations 
such as -mfpmath=sse without such issues (this should in theory work with 
-mfpmath=sse changing on a per-function basis; at least, the relevant 
variable setting is done as part of reinitialization);

* configurations with options that are expected to give unpredictable 
excess precision (-mfpmath=sse+387) or to give larger errors than arise 
with excess precision (-funsafe-math-optimizations).

The first could alternatively become an error as you suggest, or could 
make the option an alias for -ffloat-store for such front ends as the 
nearest equivalent available.  (Such an error or -ffloat-store aliasing 
would in the simplest implementation apply for all processors including 
those with no excess precision issues, though the compiler could be made 
to track whether there is a non-default TARGET_FLT_EVAL_METHOD definition 
or whether it's known that there will be no excess precision issues in any 
function.)

I do hope people will eventually implement suitable predictable semantics 
for other front ends so -ffloat-store can end up as an alias for the new 
option, flag_float_store checks in optimizers can go away and the PR can 
be closed.

-- 
Joseph S. Myers
joseph@codesourcery.com