The test optab_handler (fma_optab, mode) != CODE_FOR_nothing always fails with -E because we never proceed that far. See do_compile: /* Language-dependent initialization. Returns true on success. */ if (lang_dependent_init (main_input_filename)) compile_file (); c_common_init: if (flag_preprocess_only) { finish_options (); preprocess_file (parse_in); return false; }
Doesn't that mean -save-temps is also broken?
I think the easiest solution is to simply do switch (mode) { case SFmode: #ifdef HAVE_fmasf4 return HAVE_fmasf4; #endif break; ... } return false; instead of the optab_handler lookup.
(In reply to comment #1) > Doesn't that mean -save-temps is also broken? Yes.
Hm, the question is if it is a good idea anyway given the target and optimization attributes.
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.
Does anyone honestly expect a pre-processor macro to change due to attributes on a function? I sure don't -- that would seem to be a clear translation phase ordering violation. Setting __FP_FAST_FMA based on the command-line compiler options only would seem to be to be Good Enough.
Yes, though the issue originally came up in terms of the pragma and not the attribute, because people wanted to include the various include files that had #ifdef's to guard against builtin functions if the target switches weren't used.
Created attachment 22083 [details] Patch that redefines mode_has_fma so that it works with -save-temps
Author: meissner Date: Mon Oct 18 22:37:32 2010 New Revision: 165666 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165666 Log: Fix PR 46041 Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-cppbuiltin.c trunk/gcc/tree.h
Fixed on October 18th, 2010.