gcc doesn't accept specs options anymore

[Joel Sherrill]

On 05/07/2012 05:09 AM, Joseph S. Myers wrote:
> 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.
I have considered this over the years for RTEMS but never
gotten around to implementing it. Can you point me to a
good example?
> 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.
>


-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985