On Mon, 7 May 2012, Christian Bruel wrote:
> > What about a generic name such as -fextension- (or both -fextension- and
> > -mextension-) for options that GCC itself will ignore, if -mbsp= is
> > considered inappropriate? I'd prefer that to delimiting such options with
> > --start-specs and --
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 sever
On 05/07/2012 03:11 PM, Christian Bruel wrote:
>
>
>> What about a generic name such as -fextension- (or both -fextension- and
>> -mextension-) for options that GCC itself will ignore, if -mbsp= is
>> considered inappropriate? I'd prefer that to delimiting such options with
>> --start-specs
> What about a generic name such as -fextension- (or both -fextension- and
> -mextension-) for options that GCC itself will ignore, if -mbsp= is
> considered inappropriate? I'd prefer that to delimiting such options with
> --start-specs and --end-specs.
>
you mean, gcc would ignore options
FWIW RTEMS has long used BSP provided spec files from the command line. We have
issues with using them in that they are a clear place where we depend on
something that is compiler specific. But we do use them. If the support for the
-specs option suddenly disappeared, we would have a problem.
On Mon, 7 May 2012, Christian Bruel wrote:
> > * 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 re
> I think http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858 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
> manual.
>
> Peter
>
yes, same root problem, although BSP design is a different usage (yet
q
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
>>>
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 ?
>
>
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
Hello,
There are a few EXTRA_SPECS rules that are used to custom target runtime
support. For instance, "ldruntime" is used on superh for board
configurations and dynamically support different runtime behaviors.
Illustration of this use with a silly reduced spec
*ldruntime:
+ %{mfoo: -lfoo}
The
11 matches
Mail list logo
