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)
On Wed, 5 Nov 2008, Ian Lance Taylor wrote:
> "Joseph S. Myers" <firstname.lastname@example.org> 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
<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
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
Joseph S. Myers