This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc doesn't accept specs options anymore


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
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]