[Bug target/68028] [6/7/8 regression] Compilation error "lto1: error: target attribute or pragma changes single precision floating point" with LTO on PowerPC

[rguenth at gcc dot gnu.org]

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).