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 03:34:26PM +0200, Richard Guenther wrote:
> 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.
Richard,
It would be nice if the lto had some sort of verbose mode which
would show you the compiler flags being used for each object file
as it was processed (since there does appear to be a crude automatic
association of compiler flags done internally).
Jack