This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] Support DEC-C extensions
- From: Tristan Gingold <gingold at adacore dot com>
- To: Joseph S. Myers <joseph at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 6 Oct 2011 15:48:50 +0200
- Subject: Re: [Patch] Support DEC-C extensions
- References: <51227D85-9E15-48AB-9381-14B597C1F80B@adacore.com> <Pine.LNX.email@example.com> <07CC04EB-8EFF-4875-BA8B-D630026AE744@adacore.com> <Pine.LNX.firstname.lastname@example.org> <4E8A0AB4.email@example.com> <Pine.LNX.firstname.lastname@example.org>
On Oct 3, 2011, at 10:23 PM, Joseph S. Myers wrote:
> On Mon, 3 Oct 2011, Douglas Rupp wrote:
>> On 9/30/2011 8:19 AM, Joseph S. Myers wrote:
>>> On Fri, 30 Sep 2011, Tristan Gingold wrote:
>>>> If you prefer a target hook, I'm fine with that. I will write such a
>>>> I don't think it must be restricted to system headers, as it is possible
>>>> that the user 'imports' such a function (and define it in one of VMS
>>>> favorite languages such as macro-32 or bliss).
>>> If it's not restricted to system headers, then probably the option is
>>> better than the target hook.
>> I'm not sure I understand the reasoning here. This seems fairly VMS specific
>> so what is the downside for a target hook and user written headers?
> The language accepted by the compiler in the user's source code (as
> opposed to in system headers) shouldn't depend on the target except for
> certain well-defined areas such as target attributes and built-in
> functions; behaving the same across different systems is an important
> feature of GCC. This isn't one of those areas of target-dependence; it's
> generic syntax rather than e.g. exploiting a particular processor feature.
So the consensus is for a dedicated option. Which one do you prefer ?
I will update my patch once this is settled.