On Mon, 7 Nov 2011, Iain Sandoe wrote: > > On 7 Nov 2011, at 12:40, Richard Guenther wrote: > > > On Mon, 7 Nov 2011, Iain Sandoe wrote: > > > > > It would also be nice to preserve the Objective-C flavor (GNU/NeXT), since > > > we > > > have to make a guess for this in darwin.c when in lto. > > > > 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. > IIRC it's defined in toplev.c > > > Please provide a patch > > will try to do this (was kinda on my to-do anyway) > > > to move flag_next_runtime to properly > > use the new option mechanism to avoid the need to handle it > > in c-opts.c explicitely (and thus avoid the need to handle it > > in lto explicitely). > > one would still need deal with how to handle the case of inputs some compiled > with -flag_next_runtime and some with -flag_gnu_runtime options (as far as I > think at the moment - that's an error).
You can complain about this in lto-wrapper.c and reject the link. That said, you probably want to pass down either option to the link-stage which then hopefully complains about -fgnu-runtime -fnext-runtime. Richard.
