This is the mail archive of the 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, May 7, 2012 at 6:08 AM, Christian Bruel <> wrote:
> On 05/07/2012 12:09 PM, 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).
> True but this removes the flexibility for a user or a BSP maintainer to
> define new options, e.g to the linker not the compiler, without access
> to the compiler sources using a --spec= file..
>> * 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.
> If the option is only supported by a BSP, and not by the compiler, I
> don't see how the compiler could report it since it doesn't depend on
> static information known at build time.
> A direction would be to add this information in the user spec rules
> *ldruntime:
> + %{foo: -lfoo} %{help: "describe foo "}
> I'm not aware about such machinery. maybe an idea of improvement ?
>> 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 don't like this -mbsp= alternative a lot, seems confusing, not
> elegant, and not general for other uses (could be a runtime
> customization, not bsp).
> What about delimiters, something like --start-specs ... --end-specs ?
>> 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.
> yes it looks ok for the GCC specs, the problem is for the user spec
> files. This is a new legacy issue, I thought it was worth to either
> report it, and see if this need/can be fixed.

I think is
essentially this issue.  It can probably be closed as "won't fix",
though I notice the spec file format is still documented in the user


> many thanks
> Christian

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