On Tue, 8 Nov 2011, Iain Sandoe wrote: > > On 8 Nov 2011, at 00:21, Joseph S. Myers wrote: > > > On Mon, 7 Nov 2011, Iain Sandoe wrote: > > > > > > How is the default selected (that's not obvious to me). > > > > flag_next_runtime > > > > doesn't use options mechanisms it seems, that's bad. Both > > > > -fgnu-runtime and -fnext-runtime are frontend-only flags, they should > > > > be at least also enabled for LTO, otherwise LTO cannot do anything > > > > about the flag (and if it were LTO supported it would already be > > > > saved properly). > > > > > > for some reason it wasn't shifted to the new scheme - perhaps Joseph > > > recalls > > > why. > > > > In general I was concerned with options of relevance to multilib selection > > (although the actual changes to multilib selection didn't get > > implemented), meaning back-end and middle-end options; front-end options > > were less relevant. Making similar cleanups to front-end options (i.e. > > making as much use of .opt features as possible instead of ad hoc code) is > > certainly still worthwhile as a cleanup. (And there is still scope for > > more cleanup of some back-end options: moving some handling of enumeration > > options in override hooks to use Enum in particular.) > > I'm looking at doing this - but have a question about the meaning of "LTO" in > the options file (I've built doc from trunk and read gccint section 8). > > Does "LTO" mean that lto1 should respond to the flag? > - or does it mean that the flag should be preserved within the object (for > resurrection by lto)? > > (or something else, of course ;-)
It means the option is valid for lto1. Richard.
