https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Nick Clifton from comment #9)
> Created attachment 43318 [details]
> Proposed patch
>
> Hi Guys,
>
> Richard was right - there is code that sets extra flags based upon the
> setting of -mcpu. In fact it is just before the code he mentioned:
>
> /* For the E500 family of cores, reset the single/double FP flags to let us
> check that they remain constant across attributes or pragmas. */
>
> switch (rs6000_cpu)
> {
> case PROCESSOR_PPC8540:
> case PROCESSOR_PPC8548:
> case PROCESSOR_PPCE500MC:
> case PROCESSOR_PPCE500MC64:
> case PROCESSOR_PPCE5500:
> case PROCESSOR_PPCE6500:
> rs6000_single_float = 0;
> rs6000_double_float = 0;
> break;
>
> default:
> break;
> }
>
> This has lead me to propose the attached patch. Basically what it does is to
> tell the rs6000 backend that when it is operating in LTO mode, it should
> trust
> the function attributes and not the command line.
>
> My assumption here is that if there are any discrepancies between real
> function attributes (ie not ones generated for LTO) and the command line,
> then these will have been detected and reported during the original
> compilation.
>
> What do people think ? Is the patch OK ?
If the backend doesn't support mixing of -msingle-float/-mno-single-float
within
a compilation unit then this will only work if the user didn't mix TUs
with conflicting setting at link-time. So the following will not be diagnosed
but will instead have conflicting IL accepted silently with your
patch (with unknown effect):
> gcc -c t1.c -flto -msingle-float
> gcc -c t2.c -flto -mdouble-float
> gcc t1.o t2.o -flto
so I think it's better to have rs6000_single_float/rs6000_double_float
initialized to for example -1 and allow changing that a _single_ time,
verifying all following uses will match.
But I don't see why mixing shouldn't be possible? Maybe the target wants
to instead limit inlining of functions with differing settings instead?
If the caller/callee uses FP? (see i386.c:ix86_can_inline_p use of
cgraph_node::get (callee))->fp_expressions to guard similar things).
