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

[Ian Lance Taylor <iant@google.com>]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> 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.

My personal preference would be for the option to become a sorry() for
languages which do not support it, when used on a processor where it
ought to make a difference.

> 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.

I agree.

Ian