On 05/28/2012 06:27 PM, Joseph S. Myers wrote: > 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.
Thanks for confirming this, the question was more specifically for <%options. Today, with the current implementation, I see two uses cases: 1) The flag appears in a %< spec but is not in a .opt file -> It is *not* rejected. It is just ignored. 2) The flag appears in a user switch and in a %< spec, and not in a .opt file. -> It is rejected. To refocus on the original question from the patch. I'm still not convinced after our discussions and testings that the propagation of the user flag to the do_spec functions is required to keep the same semantic. If there is an issue with the current %< handling, could we handle this separately ? my primary focus was in matching --spec user options behavior with the .opt internal ones. > > 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). I agree. I believe my patch implements this, my focus was on not changing the current behavior for switches internally defined in a .opt (or now in a --spec file). error are still generated for other cases. Many thanks Christian
