This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: lto and compile flag associations
On Mon, May 17, 2010 at 3:21 PM, Jack Howarth <howarth@bromo.med.uc.edu> 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.
Richard.