This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] Support DEC-C extensions
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Douglas Rupp <rupp at gnat dot com>
- Cc: Tristan Gingold <gingold at adacore dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 3 Oct 2011 20:23:43 +0000 (UTC)
- 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>
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
> > > patch.
> > >
> > > 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.
Joseph S. Myers