lto and compile flag associations

Richard Guenther
Mon May 17 13:34:00 GMT 2010

On Mon, May 17, 2010 at 3:21 PM, Jack Howarth <> wrote:
> On Mon, May 17, 2010 at 02:50:27PM +0200, Richard Guenther wrote:
> ....
>> For example the C++ frontend sets flag_exceptions to 1 but the
>> command-line does not contain -fexceptions.  Or the Fortran
>> frontend might set flag_no_signed_zeros but the command-line
>> does not contain -fno-signed-zeros.  Similar the Java frontend
>> sets flag_wrapv but it's not on the command-line either.
>> Looking at the command-line for exactly those options we try
>> to match (as they change semantics) does not work reliably
>> because of that issue.
>> And for those that would work (optimization options) it doesn't
>> really matter (and we don't care at the moment).
>> The only thing where it might actually work sort-of is for
>> target options, but even that's fragile as we don't merge options
>> but take those of the first (or last) TU (so if one unit selects
>> -msse2 and one -mavx we don't necessarily get -mavx for the
>> link step).
>> Richard.
> Richard,
>   In the case of xplor-nih, there are linkages of shared libraries
> which contain a mix of c, c++ and fortran code. In these cases, I am
> worried about flags like -fno-second-underscore and -fdefault-integer-8
> which are passed only on FFLAGS. So I guess I need to explicitly look
> at the linker command outputted using -v to insure that the proper
> flags are being retained. Whether they are actually being passed
> properly for the final lto compilations is yet another question.

These are Frontend flags and they should take effect during the
compile-stage and thus be not necessary for the link stage.

>              Jack
> ps It would be really nice if lto were smart enough to tag the
> lto information in the object files with the some of the optimization
> flags such that the lowest common denominator could be used. For
> instance, if you had a.o, b.o and c.o where a.o was compiled with -O1,
> b.o with -O2 and c.o with -O3, when lto with -fwhole-program tried to
> inline between a.o and c.o, the optimization would be dropped to -O1.
> Likewise of inlining was shared between b.o and c.o, the optimization
> would be dropped to -02. The trick would be to trigger this only in
> those cases of inlining so as to not pessimize the code generation
> unnecessarily,

Well, something would be nice, but not magically choosing something,
only complaining if the result won't work as expected.


More information about the Gcc mailing list