This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Reorganize -ffast-math code.

Brad Lucier <> writes:

> Since Joseph Myers was kind enough to show an interest in my
> suggestion of
> I decided to reconstruct my changes for the current CVS head.
> The purpose here is to separate and rationalize the various
> purposes for which flag_fast_math is used in various parts of gcc.
> The following patches removes flag_fast_math from toplev.c and
> introduces two new flags
> int flag_unsafe_math_optimizations = 0;
> int flag_trapping_math = 1;
> with associated options -funsafe-math-optimizations and
> -fno-trapping-math.
> Together with the existing
> int flag_errno_math = 1;
> these three flags seem to encapsulate all the different uses
> that flag_fast_math fills at the moment.
> The -ffast-math option still exists, it simply sets these
> three flags to the opposite of their defaults; -fno-fast-math
> resets them to their defaults.  These flags can be interspersed,
> they are interpreted in order and can override each other.
> These patches also fix an association error in fold_const.c, as
> reported in optimization/2175.
> I bootstrapped the compiler with --enable-languages=c,c++,f77,objc
> on i686-pc-linux-gnu with and without these patches.  These patches
> introduce no new warnings.  I couldn't get dejagnu installed
> properly on my intel box, and right now I can't get the trunk CVS
> to build on my alphaev6-unknown-linux-gnu box, so I have no
> test results yet.  (The patches did apply cleanly on my alpha box
> with a new CVS checkout after being generated on my intel box.)
> Perhaps someone else with a working dejagnu setup and an interest
> in these patches could test them.
> Brad Lucier
> Here are some comments and questions about the patches:
> 	* gcc/config/convex/ Why is flag_fast_math checked before
> 	generating builtins?  Do these builtins incompletely implement
> 	these functions for all IEEE arguments and results?  If so, then
> 	we should go with my change to check flag_unsafe_math_optimizations
> 	instead of flag_fast_math.  If this is just to make sure that
> 	errno is set properly, this is checked in gcc/builtins.c
> 	(expand_builtin_mathfn) if flag_errno_math is 1 (the default),
> 	so the check is not needed here.
> 	* gcc/config/i386/ Same questions.
> 	* gcc/config/m68k/ Same questions.
> 	* gcc/config/mips/ Same questions.
> 	* gcc/gcc.c: __FAST_MATH__ does not appear anywhere in the source
> 	tree, and I can't see the utility of this definition.

Check on a glibc 2.1+ system <bits/mathinline.h>.  We use some inlines
if we know that the user has added -ffast-math:

/* __FAST_MATH__ is defined by gcc -ffast-math.  */
#ifdef __FAST_MATH__

I would even suggest to added flags for the two other flags so that
they can be used by system software like glibc.

 Andreas Jaeger
  SuSE Labs

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]