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.