This is the mail archive of the
mailing list for the GCC project.
Re: [4.5 C] C99-conforming excess precision (fix PR 323 for C)
"Joseph S. Myers" <firstname.lastname@example.org> 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.