[Bug lto/53777] [lto] lto does not propagate optimization flags from command lines given at "compilation time"

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Jun 26 09:10:00 GMT 2012


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-06-26
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-26 09:10:25 UTC ---
;)

There are a vast number of things the developer might expect when flags
used at compile time differ from flags used at link-optimization time.

At the moment the semantics are (roughly) that you can think of the
link-optimization time flags to be appended to the flags used at compile-time.
Thus -O2 overrides -Os here.

The implementation does not explicitely retain (all) of the compile-time
flags - they might differ between different CUs after all - but only
a very selected subset - and expects that meaningful link-optimization time
options are present.

You seem to want that code compiled with -Os would be implicitely wrapped
in a optimize/target pragma with the options specified at compile-time.
Note that this would inhibit inlining -Os code into -O2 code or vice-versa.
Note also that in your example the -O2 given at link-time would be
ignored?

Note also that the optimize attribute/pragma has serious implementation
issues and thus this kind of general use would not likely be a good idea.

Suggestions (with formal specification ;)) of how to produce from
Options(CU1), Options(CU2) ..., Options(Link-Time) a set of options
effective at link-time is welcome.  The current logic is implemented
inside lto-wrapper.c (the LTO driver) and lto-opts.c (which pre-filters
which options from compile-time are presented to the LTO driver).



More information about the Gcc-bugs mailing list