Patchwork Support DEC-C extensions

login
register
mail settings
Submitter Tristan Gingold
Date Sept. 29, 2011, 3:10 p.m.
Message ID <51227D85-9E15-48AB-9381-14B597C1F80B@adacore.com>
Download mbox | patch
Permalink /patch/116975/
State New
Headers show

Comments

Tristan Gingold - Sept. 29, 2011, 3:10 p.m.
Hi,

DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one extension that is difficult to work-around as it is used in the system headers: varargs without named argument.  It makes sense on VMS because of its ABI which pass the number of arguments used.

This patch allows such declaration when the new flag -fdecc-extensions is used (C and ObjC only as C++ already allows that).

I use the plural for consistency with other -fxxx-extensions and in case where others extensions are added.

Bootstrapped on x86_64-darwin, no regressions.

Ok for mainline ?

Tristan.

gcc/
2011-09-29  Tristan Gingold  <gingold@adacore.com>

	* doc/invoke.texi: Document -fdecc-extensions.
	* c-parser.c (c_parser_parms_list_declarator): Handle -fdecc-extensions.

gcc/c-family/
2011-09-29  Tristan Gingold  <gingold@adacore.com>

	* c.opt (fdecc-extensions): New.

gcc/testsuite/
2011-09-29  Tristan Gingold  <gingold@adacore.com>

	* gcc.dg/va-arg-4.c: New test.
	* gcc.dg/va-arg-5.c: Ditto.
Basile Starynkevitch - Sept. 29, 2011, 3:54 p.m.
On Thu, 29 Sep 2011 17:10:26 +0200
Tristan Gingold <gingold@adacore.com> wrote:

> Hi,
> 
> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one extension that is difficult to work-around as it is used in the system headers: varargs without named argument.  It makes sense on VMS because of its ABI which pass the number of arguments used.
> 

I believe that such an extension is useful on other systems, even when their ABI don't
pass the number of arguments.

The use case I would have in mind is when the signature of the called function (that is
the number & types of arguments) is determined by something else, perhaps a global
variable or data. Think e.g. of a printf-like function, except that the format string is
conventionally assigned to some fixed global before calling it.

Perhaps also the comments and explanation might reflect such kind of usage?

And perhaps then such an extension might be trigerred by a flag which don't even mention
DEC. Eg -fveryvariadic-extensions ?

Regards.
Tristan Gingold - Sept. 30, 2011, 7:24 a.m.
On Sep 29, 2011, at 5:54 PM, Basile Starynkevitch wrote:

> On Thu, 29 Sep 2011 17:10:26 +0200
> Tristan Gingold <gingold@adacore.com> wrote:
> 
>> Hi,
>> 
>> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one extension that is difficult to work-around as it is used in the system headers: varargs without named argument.  It makes sense on VMS because of its ABI which pass the number of arguments used.
>> 
> 
> I believe that such an extension is useful on other systems, even when their ABI don't
> pass the number of arguments.
> 
> The use case I would have in mind is when the signature of the called function (that is
> the number & types of arguments) is determined by something else, perhaps a global
> variable or data. Think e.g. of a printf-like function, except that the format string is
> conventionally assigned to some fixed global before calling it.

In fact you can't access to the arguments with ANSI-C as va_start needs a named argument. So you can't write such code.

Tristan.
Gabriel Dos Reis - Sept. 30, 2011, 9:10 a.m.
On Thu, Sep 29, 2011 at 10:10 AM, Tristan Gingold <gingold@adacore.com> wrote:
> Hi,
>
> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one extension that is difficult to work-around as it is used in the system headers: varargs without named argument.  It makes sense on VMS because of its ABI which pass the number of arguments used.
>
> This patch allows such declaration when the new flag -fdecc-extensions is used (C and ObjC only as C++ already allows that).
>
> I use the plural for consistency with other -fxxx-extensions and in case where others extensions are added.
>
> Bootstrapped on x86_64-darwin, no regressions.
>
> Ok for mainline ?
>

Note that

   void f(...) { }

is already valid C++, so I don't think the choice of the name
-fdecc-extensions is appropriate.
Tristan Gingold - Sept. 30, 2011, 9:38 a.m.
On Sep 30, 2011, at 11:10 AM, Gabriel Dos Reis wrote:

> On Thu, Sep 29, 2011 at 10:10 AM, Tristan Gingold <gingold@adacore.com> wrote:
>> Hi,
>> 
>> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one extension that is difficult to work-around as it is used in the system headers: varargs without named argument.  It makes sense on VMS because of its ABI which pass the number of arguments used.
>> 
>> This patch allows such declaration when the new flag -fdecc-extensions is used (C and ObjC only as C++ already allows that).
>> 
>> I use the plural for consistency with other -fxxx-extensions and in case where others extensions are added.
>> 
>> Bootstrapped on x86_64-darwin, no regressions.
>> 
>> Ok for mainline ?
>> 
> 
> Note that
> 
>   void f(...) { }
> 
> is already valid C++, so I don't think the choice of the name
> -fdecc-extensions is appropriate.

Can you suggest a name ?

Tristan.
Basile Starynkevitch - Sept. 30, 2011, 2:41 p.m.
On Fri, 30 Sep 2011 09:24:03 +0200
Tristan Gingold <gingold@adacore.com> wrote:

> 
> On Sep 29, 2011, at 5:54 PM, Basile Starynkevitch wrote:
> > I believe that such an extension is useful on other systems, even when their ABI don't
> > pass the number of arguments.
> > 
> > The use case I would have in mind is when the signature of the called function (that is
> > the number & types of arguments) is determined by something else, perhaps a global
> > variable or data. Think e.g. of a printf-like function, except that the format string is
> > conventionally assigned to some fixed global before calling it.
> 
> In fact you can't access to the arguments with ANSI-C as va_start needs a named argument. So you can't write such code.

I agree with that point, but that suggests that such a function is not DEC like. (and
IIRC, in the good days of <vaargs.h> ten years ago, not today's <stdarg.h>, such a
function was possible).

I was only saying that there is no reason to call such an extension DEC-like. And
apparently, you tested it on a x86/Linux which is not a DEC system :-)


And I do think that such an extension can be useful.

Cheers.
Joseph S. Myers - Sept. 30, 2011, 2:43 p.m.
On Thu, 29 Sep 2011, Tristan Gingold wrote:

> Hi,
> 
> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least 
> one extension that is difficult to work-around as it is used in the 
> system headers: varargs without named argument.  It makes sense on VMS 
> because of its ABI which pass the number of arguments used.

If it's about system headers, is there a reason you used a command-line 
option rather than having a target hook that controls whether the front 
end accepts this in system headers (only)?
Tristan Gingold - Sept. 30, 2011, 2:55 p.m.
On Sep 30, 2011, at 4:43 PM, Joseph S. Myers wrote:

> On Thu, 29 Sep 2011, Tristan Gingold wrote:
> 
>> Hi,
>> 
>> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least 
>> one extension that is difficult to work-around as it is used in the 
>> system headers: varargs without named argument.  It makes sense on VMS 
>> because of its ABI which pass the number of arguments used.
> 
> If it's about system headers, is there a reason you used a command-line 
> option rather than having a target hook that controls whether the front 
> end accepts this in system headers (only)?

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).

Tristan.
Joseph S. Myers - Sept. 30, 2011, 3:19 p.m.
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.
Tristan Gingold - Oct. 3, 2011, 1:16 p.m.
On Sep 30, 2011, at 5:19 PM, 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.

Is it ok with this option name (-fdecc-extensions) or do you prefer a more generic option name,
such as -fallow-unnamed-variadic-functions ?

Tristan.
Basile Starynkevitch - Oct. 3, 2011, 1:36 p.m.
On Mon, Oct 03, 2011 at 03:16:11PM +0200, Tristan Gingold wrote:
> 
> On Sep 30, 2011, at 5:19 PM, Joseph S. Myers wrote:
> 
> Is it ok with this option name (-fdecc-extensions) or do you prefer a more generic option name,
> such as -fallow-unnamed-variadic-functions ?


My preference is to avoid using the -fdecc-extensions and use a more explanative & generic option name.

But my (non-native English speaker) understanding of
-fallow-unnamed-variadic-functions is misleading: I read it to allow
anonymous functions (think of lambda) which happends to be variadic, which
is not what your patch gives.

What about -fallow-fully-variadic-functions or
-fallow-very-variadic-functions ?


And we could also imagine having a GCC #pragma which change the acceptance
of variadic functions.

By the way, I also regret the name of -fms-extensions option;
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Unnamed-Fields.html#Unnamed-Fields
because accepting an unamed field should not be percieved as MicroSoft
specific, but as a unseful language extension.

[My point is that language extensions should not be enabled by options
containing a brand or a trademark which suggested them, they should be named
by options which are evocative of what the extension provides.]

Regards.
Andreas Schwab - Oct. 3, 2011, 2:32 p.m.
Basile Starynkevitch <basile@starynkevitch.net> writes:

> What about -fallow-fully-variadic-functions or
> -fallow-very-variadic-functions ?

-fallow-parameterless-variadic-functions

Andreas.
Gabriel Dos Reis - Oct. 3, 2011, 3:35 p.m.
On Mon, Oct 3, 2011 at 8:16 AM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Sep 30, 2011, at 5:19 PM, 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.
>
> Is it ok with this option name (-fdecc-extensions) or do you prefer a more generic option name,
> such as -fallow-unnamed-variadic-functions ?
>

As observed earlier, there is nothing DEC-C specific about this, so
-fdecc-extensions isnt
appropriate.

"unnamed variadic functions" sounds as if the function itself is
unnamed, so not good.


-funnamed-variadic-parameter
-fpointless-variadic-functions
Douglas B Rupp - Oct. 3, 2011, 7:19 p.m.
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?
Joseph S. Myers - Oct. 3, 2011, 8:23 p.m.
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.
Douglas B Rupp - Oct. 3, 2011, 8:28 p.m.
On 10/3/2011 1:23 PM, Joseph S. Myers wrote:
> 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.
>

I understand now, thanks for explaining.
Pedro Alves - Oct. 4, 2011, 9:59 a.m.
On Monday 03 October 2011 21:23:43, 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
> > > > 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.

So I take it a `void foo(...);' declaration to mean the same thing
as an unprototyped `void foo();'?  (If so, I think that should be
explicit in the documentation).  That is, decc system headers are
probably declaring with:

extern void foo(...);

and then the function is defined somewhere with, say:

void foo(int a, int b, void *c)
{
  ...
}

Do we need to consider ABIs that have calling conventions that
treat unprototyped and varargs functions differently? (is there any?)
Tristan Gingold - Oct. 4, 2011, 10:07 a.m.
On Oct 4, 2011, at 11:59 AM, Pedro Alves wrote:

> On Monday 03 October 2011 21:23:43, 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
>>>>> 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.
> 
> So I take it a `void foo(...);' declaration to mean the same thing
> as an unprototyped `void foo();'?

No, that's not the case.  This is a full prototype.

>  (If so, I think that should be
> explicit in the documentation).  That is, decc system headers are
> probably declaring with:
> 
> extern void foo(...);
> 
> and then the function is defined somewhere with, say:
> 
> void foo(int a, int b, void *c)
> {
>  …
> }

No.

> Do we need to consider ABIs that have calling conventions that
> treat unprototyped and varargs functions differently? (is there any?)

(Yes: x86-64)

Tristan.
Gabriel Dos Reis - Oct. 4, 2011, 10:16 a.m.
On Tue, Oct 4, 2011 at 4:59 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Monday 03 October 2011 21:23:43, 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
>> > > > 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.
>
> So I take it a `void foo(...);' declaration to mean the same thing
> as an unprototyped `void foo();'?  (If so, I think that should be
> explicit in the documentation).  That is, decc system headers are
> probably declaring with:
>
> extern void foo(...);
>
> and then the function is defined somewhere with, say:
>
> void foo(int a, int b, void *c)
> {
>  ...
> }
>
> Do we need to consider ABIs that have calling conventions that
> treat unprototyped and varargs functions differently? (is there any?)

Could you elaborate on the equivalence of these declarations?
Pedro Alves - Oct. 4, 2011, 10:46 a.m.
On Tuesday 04 October 2011 11:16:30, Gabriel Dos Reis wrote:

> > Do we need to consider ABIs that have calling conventions that
> > treat unprototyped and varargs functions differently? (is there any?)
> 
> Could you elaborate on the equivalence of these declarations?

I expected that with:

  extern void foo();
  extern void bar(...);
  foo (1, 2, 0.3f, NULL, 5);
  bar (1, 2, 0.3f, NULL, 5);

the compiler would emit the same for both of those
calls (calling convention wise).  That is, for example,
on x86-64, %rax is set to 1 (number of floating point
parameters passed to the function in SSE registers) in
both cases.

But not to be equivalent at the source level, that is:

  extern void foo();
  extern void foo(int a);
  extern void bar(...);
  extern void bar(int a);

should be a "conflicting types for ’bar’" error in C.
Douglas B Rupp - Oct. 4, 2011, 6:24 p.m.
On 10/3/2011 8:35 AM, Gabriel Dos Reis wrote:
> "unnamed variadic functions" sounds as if the function itself is
> unnamed, so not good.
>
>
> -funnamed-variadic-parameter

How about
-fvariadic-parameters-unnamed

there's already a -fvariadic-macros, so maybe putting variadic first is 
more consistent?
Gabriel Dos Reis - Oct. 6, 2011, 10:45 a.m.
On Tue, Oct 4, 2011 at 5:46 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Tuesday 04 October 2011 11:16:30, Gabriel Dos Reis wrote:
>
>> > Do we need to consider ABIs that have calling conventions that
>> > treat unprototyped and varargs functions differently? (is there any?)
>>
>> Could you elaborate on the equivalence of these declarations?
>
> I expected that with:
>
>  extern void foo();
>  extern void bar(...);
>  foo (1, 2, 0.3f, NULL, 5);
>  bar (1, 2, 0.3f, NULL, 5);
>
> the compiler would emit the same for both of those
> calls (calling convention wise).  That is, for example,
> on x86-64, %rax is set to 1 (number of floating point
> parameters passed to the function in SSE registers) in
> both cases.

Except that variadics use a different kind of calling convention
than the rest.

>
> But not to be equivalent at the source level, that is:
>
>  extern void foo();
>  extern void foo(int a);
>  extern void bar(...);
>  extern void bar(int a);
>
> should be a "conflicting types for ’bar’" error in C.
>
> --
> Pedro Alves
>
Gabriel Dos Reis - Oct. 6, 2011, 10:49 a.m.
On Tue, Oct 4, 2011 at 1:24 PM, Douglas Rupp <rupp@gnat.com> wrote:
> On 10/3/2011 8:35 AM, Gabriel Dos Reis wrote:
>>
>> "unnamed variadic functions" sounds as if the function itself is
>> unnamed, so not good.
>>
>>
>> -funnamed-variadic-parameter
>
> How about
> -fvariadic-parameters-unnamed
>
> there's already a -fvariadic-macros, so maybe putting variadic first is more
> consistent?

consistent with what?
Consistency would imply -fvariadic-functions.  But that does not make
much sense since variadic functions already exist in C.

-fvariadic-parameters-unnamed sounds as if the function could have
several variadic parameters, but that is what is being proposed.
Tristan Gingold - Oct. 6, 2011, 1:48 p.m.
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
>>>> 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.

So the consensus is for a dedicated option.  Which one do you prefer ?

-funnamed-variadic-parameter
-fpointless-variadic-functions
-fallow-parameterless-variadic-functions

I will update my patch once this is settled.

Thanks,
Tristan.
Joseph S. Myers - Oct. 6, 2011, 2:12 p.m.
On Thu, 6 Oct 2011, Tristan Gingold wrote:

> So the consensus is for a dedicated option.  Which one do you prefer ?
> 
> -funnamed-variadic-parameter
> -fpointless-variadic-functions
> -fallow-parameterless-variadic-functions

I prefer -fallow-parameterless-variadic-functions.

Patch

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index e6ac5dc..4879cff 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -739,6 +739,10 @@  fconstexpr-depth=
 C++ ObjC++ Joined RejectNegative UInteger Var(max_constexpr_depth) Init(512)
 -fconstexpr-depth=<number>	Specify maximum constexpr recursion depth
 
+fdecc-extensions
+C ObjC Var(flag_decc_extensions)
+Enable DEC-C language extensions
+
 fdeduce-init-list
 C++ ObjC++ Var(flag_deduce_init_list) Init(1)
 -fno-deduce-init-list	disable deduction of std::initializer_list for a template type parameter from a brace-enclosed initializer-list
diff --git a/gcc/c-parser.c b/gcc/c-parser.c
index ff376df..788d13c 100644
--- a/gcc/c-parser.c
+++ b/gcc/c-parser.c
@@ -3159,10 +3159,19 @@  c_parser_parms_list_declarator (c_parser *parser, tree attrs, tree expr)
   if (c_parser_next_token_is (parser, CPP_ELLIPSIS))
     {
       struct c_arg_info *ret = build_arg_info ();
-      /* Suppress -Wold-style-definition for this case.  */
-      ret->types = error_mark_node;
-      error_at (c_parser_peek_token (parser)->location,
-		"ISO C requires a named argument before %<...%>");
+
+      if (flag_decc_extensions)
+        {
+          /* F (...) is allowed by DEC-C.  */
+          ret->types = NULL_TREE;
+        }
+      else
+        {
+          /* Suppress -Wold-style-definition for this case.  */
+          ret->types = error_mark_node;
+          error_at (c_parser_peek_token (parser)->location,
+                    "ISO C requires a named argument before %<...%>");
+        }
       c_parser_consume_token (parser);
       if (c_parser_next_token_is (parser, CPP_CLOSE_PAREN))
 	{
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e166964..1fceace 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -170,7 +170,7 @@  in the following sections.
 @item C Language Options
 @xref{C Dialect Options,,Options Controlling C Dialect}.
 @gccoptlist{-ansi  -std=@var{standard}  -fgnu89-inline @gol
--aux-info @var{filename} @gol
+-aux-info @var{filename} -fdecc-extensions @gol
 -fno-asm  -fno-builtin  -fno-builtin-@var{function} @gol
 -fhosted  -ffreestanding -fopenmp -fms-extensions -fplan9-extensions @gol
 -trigraphs  -no-integrated-cpp  -traditional  -traditional-cpp @gol
@@ -1733,6 +1733,16 @@  fields declared using a typedef.  @xref{Unnamed Fields,,Unnamed
 struct/union fields within structs/unions}, for details.  This is only
 supported for C, not C++.
 
+@item -fdecc-extensions
+Accept some non-standard constructs used by DEC-C in VMS header files.
+
+This allows varargs functions without named argument.  VMS is able to
+support this feature because of its call convention which pass the
+number of arguments in a register.  Although it is possible to define
+such a function, this is not very usefull as it is not possible to read
+the arguments.  This is only supported for C as this construct is
+allowed by C++.
+
 @item -trigraphs
 @opindex trigraphs
 Support ISO C trigraphs.  The @option{-ansi} option (and @option{-std}
diff --git a/gcc/testsuite/gcc.dg/va-arg-4.c b/gcc/testsuite/gcc.dg/va-arg-4.c
new file mode 100644
index 0000000..6d737c4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/va-arg-4.c
@@ -0,0 +1,3 @@ 
+/* { dg-do compile } */
+#include <stdarg.h>
+extern void baz(...);	/* { dg-error "requires a named argument" } */
diff --git a/gcc/testsuite/gcc.dg/va-arg-5.c b/gcc/testsuite/gcc.dg/va-arg-5.c
new file mode 100644
index 0000000..015f592
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/va-arg-5.c
@@ -0,0 +1,4 @@ 
+/* { dg-do compile } */
+/* { dg-options "-fdecc-extensions" } */
+#include <stdarg.h>
+extern void baz(...);