This is the mail archive of the
mailing list for the GCC project.
Re: gcc doesn't accept specs options anymore
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Christian Bruel <christian dot bruel at st dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 7 May 2012 10:09:54 +0000 (UTC)
- Subject: Re: gcc doesn't accept specs options anymore
- References: <4FA79172.firstname.lastname@example.org>
On Mon, 7 May 2012, Christian Bruel wrote:
> Making the driver aware about all possible user defined options seems
> unpredictable. Was there any justification on removing this
> functionality or did I miss a point with the EXTRA_SPECS ?
There are several motivations behind requiring all options to be defined
in .opt files, including:
* For multilibs to be selected based on the semantics of options, using
values set in gcc_options structures by the same code as in cc1, rather
than by textual matching attempting to replicate semantics, the driver
needs to understand the semantics of options as similarly as possible to
cc1, rather than treating any options purely textually.
* Every option supported by the compiler should be listed in --help (and
if the missing help information were all filled it, we could then make it
a build failure to have an option without help information).
* Structured option information enables consistency in how options are
processed and errors given for unknown options or arguments.
* It would be useful for the compiler to be able to export structured
information about all its options for use by tools such as IDEs.
There is certainly room for more extensibility in option handling -
ideally there would not be one big enum with OPT_* values for all options
and one header with all the macros and structures, but instead front-end
and back-end options would use some form of separate namespace for their
options so the language- and target-independent compiler doesn't see the
options for other parts of the compiler; that fits into the modularity
theme that ideally it would be possible to build multiple front ends and
back ends into the compiler at once, or to build front ends and back ends
separately from the compiler. But defining options through use in specs
wouldn't be part of that; rather more structured information about each
option would need to be provided somehow by a separately built front end
or back end.
If you want -m options to select arbitrary board support packages (and the
existing ability to use -T to name a linker script isn't sufficient), then
a -mbsp= option, whose argument is not interpreted by GCC but may be
processed by whatever specs you are adding after GCC is installed, would
seem better than lots of separate -m options.
As for options in specs included with GCC: they are all meant to be in the
.opt files. I went through all the specs in all the config/ headers in
GCC and added options found to .opt files before disallowing options not
included in .opt files, but as there are about 500 such headers it's quite
possible I missed some specs-defined options in the process.
Joseph S. Myers