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

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 5 Feb 2018, nickc at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028
> 
> --- Comment #11 from Nick Clifton <nickc at redhat dot com> ---
> Hi Richard,
> 
> > 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
> 
> But even without the patch, if the user does the above, but leaves out
> the final -flto then the problem will still not be diagnosed:
> 
>  gcc -c t1.c -flto -msingle-float
>  gcc -c t2.c -flto -mdouble-float
>  gcc t1.o t2.o 
> 
> That is, unless the linker detects and reports this problem.  Which it does.
> There are tags recorded in the build notes which specify the precision of
> floating point used, and the linker will complain if these do not match.
> 
> So, since the linker will report conflicts there is no need for the LTO 
> compiler to do so.   Especially when, as this bug report shows, it gets
> the warning wrong under some circumstances.
> 
> So I still think that my patch is viable.  Comments ?

I'll leave that to the target maintainers to decide -- just wanted to
note that the flags can get mixed by the user via different TUs.  Note
that with your patch what you likely get then is simply forcing
a random -m{single,double}-float on the LTO TU.  You might be lucky
enough for WPA to order ltrans units in just a way that the linker
will not complain in the end but the flags are not in effect in a way
the user intended.

So I think the UNKNOWN initialized variant would be safer, overriding
exactly once and only diagnosing mismatches.