This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: lto and compile flag associations


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.
              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,


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]