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 ? Cheers Nick