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