This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [driver, LTO Patch]: Resurrect user specs support
On Tue, 29 May 2012, Christian Bruel wrote:
> > 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.
I don't really see that as a use case; it's more a matter of an internal
consistency check that could be done but isn't. I'm only concerned about
cases where the option is actually passed on the command line to the
driver.
> 2) The flag appears in a user switch and in a %< spec, and not in a .opt
> file.
> -> It is rejected.
There are also cases:
* The option, passed by the user, is in a .opt file, a %< spec but no
other spec. (Should be accepted.)
* The option, passed by the user, is in a .opt file and no spec at all.
(Should be 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.
With the proposed change to the rules for when a spec serves to validate
an option, all settings of the "validated" field need to be reviewed to
make sure that they are in accordance with the new rules - and that it is
transparent to human readers of the code that they are in accordance with
the new rules. If you don't think propagation is needed to do_spec
functions, then it should be possible to remove the "validated" setting in
there, with a proper explanation of the order in which the various
relevant functions are called and where "validated" will previously or
subsequently be set.
--
Joseph S. Myers
joseph@codesourcery.com