[Bug c/46041] __FP_FAST_FMA not defined with -E

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46041

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2010-10-18 15:11:54         |
         AssignedTo|unassigned at gcc dot       |meissner at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #5 from Michael Meissner <meissner at gcc dot gnu.org> 2010-10-18 15:26:13 UTC ---
Yes, -save-temps would be broken.  I noticed this after submitting the bug when
I tried to patch glibc's math.h and I happened to use -save-temps, and it
didn't seem to work, and I was just about to investigate it when I needed to go
home.

The suggestion to use HAVE_fma<mode>4 instead of the check on the builtin array
will probably work for normal -save-temps.  However, for target specific
functions, we may need to go to using a conditional macro for these.

However, Richard Guenther has a point, that it really doesn't work too well
when you consider target specific attributes.  Frankly, I hadn't thought about
-save-temps when I first contemplated target attributes in the first place
(even though I originally added -save-temps many years ago).  The -save-temps
switch doesn't work in general when functions have different target attributes
that will change the macros being defined.  I would imagine -E would have the
same problem.  The only way I can see to do this 'right' is to move -save-temps
into the cpp handling in the compiler proper, rather than doing two passes like
we do now. In the old days, we had to do two passes, because cpp was a separate
process.

While this might fix -save-temps, I'm still not sure what we can do about -E.