On Mon, 28 May 2012, Christian Bruel wrote: > > > On 05/28/2012 01:11 PM, Joseph S. Myers wrote: > > On Mon, 28 May 2012, Christian Bruel wrote: > > > >> I shared the same concern, however, after playing bits with spec toys, I > >> couldn't a find a way to get a %< switch recognition failure, since the > >> switches passed on the command line at this point are already validated > >> if necessary. > > > > Suppose with the existing sources an option (in a .opt file) is matched by > > a $< spec, and not by any other spec. Will it be rejected by the driver? > > It shouldn't be. > > indeed, it's not rejected if it is present in a .opt file. I was > concerned that it will not be rejected even if not in any .opt (or now > in --specs). Which was what the validated setting seemed to imply. > > Should it be rejected ? probably. But this is not implied by the --spec > changes.
The existing rule is supposed to be: options are only accepted if in *both* a .opt file *and* a spec. If not in a .opt file, the common machinery will reject them; if in a .opt file but not a spec, the driver's own validation machinery will reject them. If the driver's own validation machinery isn't rejecting them, that indicates that some spec has handled them. It's possible there's more than one piece of code relating to accepting such options and some such code is redundant. (This can't be tested with options starting -f or -m because of the specs passing all such options to cc1.) The new semantics are supposed to be, I think: an option in a .opt file is accepted if any spec matches it (same as now), an option not in a .opt file is only accepted if a user spec matches it and not simply because of a match from a built-in spec (where built-in specs are considered to include those generated by some of GCC's own runtime libraries). -- Joseph S. Myers jos...@codesourcery.com
