| Message ID | 51227D85-9E15-48AB-9381-14B597C1F80B@adacore.com |
|---|---|
| State | New |
| Headers | show |
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.
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.
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.
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.
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.
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)?
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.
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.
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.
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.
Basile Starynkevitch <basile@starynkevitch.net> writes: > What about -fallow-fully-variadic-functions or > -fallow-very-variadic-functions ? -fallow-parameterless-variadic-functions Andreas.
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
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?
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.
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.
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?)
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.
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?
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.
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?
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 >
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.
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.
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.
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(...);