Re: c: tree: target: C2x (...) function prototypes and va_start relaxation
On Sat, 25 Nov 2023, Gerald Pfeifer wrote: > On Fri, 21 Oct 2022, Joseph Myers wrote: > > C2x allows function prototypes to be given as (...), a prototype > > meaning a variable-argument function with no named arguments. > > I noticed this did not make it into gcc-13/changes.html ? Was that > intentional? It's there (N2975, Relax requirements for variadic parameter lists). -- Joseph S. Myers jos...@codesourcery.com
Re: c: tree: target: C2x (...) function prototypes and va_start relaxation
On Fri, 21 Oct 2022, Joseph Myers wrote: > C2x allows function prototypes to be given as (...), a prototype > meaning a variable-argument function with no named arguments. I noticed this did not make it into gcc-13/changes.html ? Was that intentional? Gerald
Re: c: tree: target: C2x (...) function prototypes and va_start relaxation
> And also: > > FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O0 execution test > FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O1 execution test > FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 execution test > FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O3 -g execution test > FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -Os execution test > FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 -flto > -fno-use-linker-plugin -flto-partition=none execution test FAIL: > gcc.dg/torture/c2x-stdarg-split-1a.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects execution test The implementation does not work on some targets, see PR target/107453. -- Eric Botcazou
Re: c: tree: target: C2x (...) function prototypes and va_start relaxation
On Fri, 2022-11-04 at 13:29 +0800, Xi Ruoyao via Gcc-patches wrote: > On Fri, 2022-10-21 at 22:15 +, Joseph Myers wrote: > > > * config/loongarch/loongarch.cc > > (loongarch_setup_incoming_varargs): Likewise. > > Hi, > > One test fails on loongarch64-linux-gnu: > > FAIL: gcc.dg/c2x-stdarg-4.c execution test And also: FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O0 execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O1 execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O3 -g execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -Os execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test > > I've not got time to debug the issue yet. > -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: c: tree: target: C2x (...) function prototypes and va_start relaxation
On Fri, 2022-10-21 at 22:15 +, Joseph Myers wrote: > * config/loongarch/loongarch.cc > (loongarch_setup_incoming_varargs): Likewise. Hi, One test fails on loongarch64-linux-gnu: FAIL: gcc.dg/c2x-stdarg-4.c execution test I've not got time to debug the issue yet. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: c: tree: target: C2x (...) function prototypes and va_start relaxation
On Tue, Oct 25, 2022 at 9:42 PM Joseph Myers wrote:
>
> On Tue, 25 Oct 2022, Richard Biener wrote:
>
> > You are missing to stream the new type flag in tree-streamer-{in,out}.cc
> > and checking for tree merging in lto-common.cc:compare_tree_sccs_1
> >
> > Otherwise looks reasonable. Can you add a (multi TU) runtime testcase to
> > the
> > torture exercising the feature so we can see any ABI issues?
>
> I've made those changes. Those in turn showed up the need for a
> change in fortran/trans-types.cc (to avoid using
> build_varargs_function_type_vec when what was wanted was an
> unprototyped function type rather than a (...) prototype) to avoid a
> failure of gfortran.dg/lto/pr40724.
>
> I've added a two-file testcase to gcc.dg/torture/. I've also made the
> execution tests cover the case where there are named arguments but the
> last named argument has a declaration that results in undefined
> behavior in previous C standard versions, such as a type changed by
> the default argument promotions.
>
> Here is the revised patch version.
OK.
Thanks,
Richard.
> c: tree: target: C2x (...) function prototypes and va_start relaxation
>
> C2x allows function prototypes to be given as (...), a prototype
> meaning a variable-argument function with no named arguments. To
> allow such functions to access their arguments, requirements for
> va_start calls are relaxed so it ignores all but its first argument
> (i.e. subsequent arguments, if any, can be arbitrary pp-token
> sequences).
>
> Implement this feature accordingly. The va_start relaxation in
> is itself easy: __builtin_va_start already supports a
> second argument of 0 instead of a parameter name, and calls get
> converted internally to the form using 0 for that argument, so
> just needs changing to use a variadic macro that passes 0
> as the second argument of __builtin_va_start. (This is done only in
> C2x mode, on the expectation that users of older standard would expect
> unsupported uses of va_start to be diagnosed.)
>
> For the (...) functions, it's necessary to distinguish these from
> unprototyped functions, whereas previously C++ (...) functions and
> unprototyped functions both used NULL TYPE_ARG_TYPES. A flag is added
> to tree_type_common to mark the (...) functions; as discussed on gcc@,
> doing things this way is likely to be safer for unchanged code in GCC
> than adding a different form of representation in TYPE_ARG_TYPES, or
> adding a flag that instead signals that the function is unprototyped.
>
> There was previously an option
> -fallow-parameterless-variadic-functions to enable support for (...)
> prototypes. The support was incomplete - it treated the functions as
> unprototyped, and only parsed some declarations, not e.g.
> "int g (int (...));". This option is changed into a no-op ignored
> option; (...) is always accepted syntactically, with a pedwarn_c11
> call to given required diagnostics when appropriate. The peculiarity
> of a parameter list with __attribute__ followed by '...' being
> accepted with that option is removed.
>
> Interfaces in tree.cc that create function types are adjusted to set
> this flag as appropriate. It is of course possible that some existing
> users of the functions to create variable-argument functions actually
> wanted unprototyped functions in the no-named-argument case, rather
> than functions with a (...) prototype; some such cases in c-common.cc
> (for built-in functions and implicit function declarations) turn out
> to need updating for that reason.
>
> I didn't do anything to change how the C++ front end creates (...)
> function types. It's very likely there are unchanged places in the
> compiler that in fact turn out to need changes to work properly with
> (...) function prototypes.
>
> Target setup_incoming_varargs hooks, where they used the information
> passed about the last named argument, needed updating to avoid using
> that information in the (...) case. Note that apart from the x86
> changes, I haven't done any testing of those target changes beyond
> building cc1 to check for syntax errors. It's possible further
> target-specific fixes will be needed; target maintainers should watch
> out for failures of c2x-stdarg-4.c or c2x-stdarg-split-1a.c, the
> execution tests, which would indicate that this feature is not working
> correctly. Those tests also verify the case where there are named
> arguments but the last named argument has a declaration that results
> in undefined behavior in previous C standard versions, such as a type
> changed by the default argument promotions.
>
> Bootstrapped with no regressions for x86_64-pc-linux-gnu.
>
> gcc/
> * config/aarch64/aarch64.cc (aarch64_setup_incoming_varargs):
> Check TYPE_NO_NAMED_ARGS_STDARG_P.
> * config/alpha/alpha.cc (alpha_setup_incoming_varargs): Likewise.
> * config/arc/arc.cc (arc_setup_incoming_varargs): Likewise.
> * config/arm/arm.cc (arm_setup_incoming_varargs): Likewise.
>
Re: c: tree: target: C2x (...) function prototypes and va_start relaxation
On Tue, 25 Oct 2022, Richard Biener wrote:
> You are missing to stream the new type flag in tree-streamer-{in,out}.cc
> and checking for tree merging in lto-common.cc:compare_tree_sccs_1
>
> Otherwise looks reasonable. Can you add a (multi TU) runtime testcase to the
> torture exercising the feature so we can see any ABI issues?
I've made those changes. Those in turn showed up the need for a
change in fortran/trans-types.cc (to avoid using
build_varargs_function_type_vec when what was wanted was an
unprototyped function type rather than a (...) prototype) to avoid a
failure of gfortran.dg/lto/pr40724.
I've added a two-file testcase to gcc.dg/torture/. I've also made the
execution tests cover the case where there are named arguments but the
last named argument has a declaration that results in undefined
behavior in previous C standard versions, such as a type changed by
the default argument promotions.
Here is the revised patch version.
c: tree: target: C2x (...) function prototypes and va_start relaxation
C2x allows function prototypes to be given as (...), a prototype
meaning a variable-argument function with no named arguments. To
allow such functions to access their arguments, requirements for
va_start calls are relaxed so it ignores all but its first argument
(i.e. subsequent arguments, if any, can be arbitrary pp-token
sequences).
Implement this feature accordingly. The va_start relaxation in
is itself easy: __builtin_va_start already supports a
second argument of 0 instead of a parameter name, and calls get
converted internally to the form using 0 for that argument, so
just needs changing to use a variadic macro that passes 0
as the second argument of __builtin_va_start. (This is done only in
C2x mode, on the expectation that users of older standard would expect
unsupported uses of va_start to be diagnosed.)
For the (...) functions, it's necessary to distinguish these from
unprototyped functions, whereas previously C++ (...) functions and
unprototyped functions both used NULL TYPE_ARG_TYPES. A flag is added
to tree_type_common to mark the (...) functions; as discussed on gcc@,
doing things this way is likely to be safer for unchanged code in GCC
than adding a different form of representation in TYPE_ARG_TYPES, or
adding a flag that instead signals that the function is unprototyped.
There was previously an option
-fallow-parameterless-variadic-functions to enable support for (...)
prototypes. The support was incomplete - it treated the functions as
unprototyped, and only parsed some declarations, not e.g.
"int g (int (...));". This option is changed into a no-op ignored
option; (...) is always accepted syntactically, with a pedwarn_c11
call to given required diagnostics when appropriate. The peculiarity
of a parameter list with __attribute__ followed by '...' being
accepted with that option is removed.
Interfaces in tree.cc that create function types are adjusted to set
this flag as appropriate. It is of course possible that some existing
users of the functions to create variable-argument functions actually
wanted unprototyped functions in the no-named-argument case, rather
than functions with a (...) prototype; some such cases in c-common.cc
(for built-in functions and implicit function declarations) turn out
to need updating for that reason.
I didn't do anything to change how the C++ front end creates (...)
function types. It's very likely there are unchanged places in the
compiler that in fact turn out to need changes to work properly with
(...) function prototypes.
Target setup_incoming_varargs hooks, where they used the information
passed about the last named argument, needed updating to avoid using
that information in the (...) case. Note that apart from the x86
changes, I haven't done any testing of those target changes beyond
building cc1 to check for syntax errors. It's possible further
target-specific fixes will be needed; target maintainers should watch
out for failures of c2x-stdarg-4.c or c2x-stdarg-split-1a.c, the
execution tests, which would indicate that this feature is not working
correctly. Those tests also verify the case where there are named
arguments but the last named argument has a declaration that results
in undefined behavior in previous C standard versions, such as a type
changed by the default argument promotions.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/
* config/aarch64/aarch64.cc (aarch64_setup_incoming_varargs):
Check TYPE_NO_NAMED_ARGS_STDARG_P.
* config/alpha/alpha.cc (alpha_setup_incoming_varargs): Likewise.
* config/arc/arc.cc (arc_setup_incoming_varargs): Likewise.
* config/arm/arm.cc (arm_setup_incoming_varargs): Likewise.
* config/csky/csky.cc (csky_setup_incoming_varargs): Likewise.
* config/epiphany/epiphany.cc (epiphany_setup_incoming_varargs):
Likewise.
* config/fr30/fr30.cc (fr30_setup_incoming_varargs): Likewise.
*
Re: c: tree: target: C2x (...) function prototypes and va_start relaxation
On Sat, Oct 22, 2022 at 1:03 AM Joseph Myers wrote:
>
> C2x allows function prototypes to be given as (...), a prototype
> meaning a variable-argument function with no named arguments. To
> allow such functions to access their arguments, requirements for
> va_start calls are relaxed so it ignores all but its first argument
> (i.e. subsequent arguments, if any, can be arbitrary pp-token
> sequences).
>
> Implement this feature accordingly. The va_start relaxation in
> is itself easy: __builtin_va_start already supports a
> second argument of 0 instead of a parameter name, and calls get
> converted internally to the form using 0 for that argument, so
> just needs changing to use a variadic macro that passes 0
> as the second argument of __builtin_va_start. (This is done only in
> C2x mode, on the expectation that users of older standard would expect
> unsupported uses of va_start to be diagnosed.)
>
> For the (...) functions, it's necessary to distinguish these from
> unprototyped functions, whereas previously C++ (...) functions and
> unprototyped functions both used NULL TYPE_ARG_TYPES. A flag is added
> to tree_type_common to mark the (...) functions; as discussed on gcc@,
> doing things this way is likely to be safer for unchanged code in GCC
> than adding a different form of representation in TYPE_ARG_TYPES, or
> adding a flag that instead signals that the function is unprototyped.
>
> There was previously an option
> -fallow-parameterless-variadic-functions to enable support for (...)
> prototypes. The support was incomplete - it treated the functions as
> unprototyped, and only parsed some declarations, not e.g.
> "int g (int (...));". This option is changed into a no-op ignored
> option; (...) is always accepted syntactically, with a pedwarn_c11
> call to given required diagnostics when appropriate. The peculiarity
> of a parameter list with __attribute__ followed by '...' being
> accepted with that option is removed.
>
> Interfaces in tree.cc that create function types are adjusted to set
> this flag as appropriate. It is of course possible that some existing
> users of the functions to create variable-argument functions actually
> wanted unprototyped functions in the no-named-argument case, rather
> than functions with a (...) prototype; some such cases in c-common.cc
> (for built-in functions and implicit function declarations) turn out
> to need updating for that reason.
>
> I didn't do anything to change how the C++ front end creates (...)
> function types. It's very likely there are unchanged places in the
> compiler that in fact turn out to need changes to work properly with
> (...) function prototypes.
>
> Target setup_incoming_varargs hooks, where they used the information
> passed about the last named argument, needed updating to avoid using
> that information in the (...) case. Note that apart from the x86
> changes, I haven't done any testing of those target changes beyond
> building cc1 to check for syntax errors. It's possible further
> target-specific fixes will be needed; target maintainers should watch
> out for failures of c2x-stdarg-4.c, the execution test, which would
> indicate that this feature is not working correctly.
>
> Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit?
You are missing to stream the new type flag in tree-streamer-{in,out}.cc
and checking for tree merging in lto-common.cc:compare_tree_sccs_1
Otherwise looks reasonable. Can you add a (multi TU) runtime testcase to the
torture exercising the feature so we can see any ABI issues?
Thanks,
Richard.
> gcc/
> * config/aarch64/aarch64.cc (aarch64_setup_incoming_varargs):
> Check TYPE_NO_NAMED_ARGS_STDARG_P.
> * config/alpha/alpha.cc (alpha_setup_incoming_varargs): Likewise.
> * config/arc/arc.cc (arc_setup_incoming_varargs): Likewise.
> * config/arm/arm.cc (arm_setup_incoming_varargs): Likewise.
> * config/csky/csky.cc (csky_setup_incoming_varargs): Likewise.
> * config/epiphany/epiphany.cc (epiphany_setup_incoming_varargs):
> Likewise.
> * config/fr30/fr30.cc (fr30_setup_incoming_varargs): Likewise.
> * config/frv/frv.cc (frv_setup_incoming_varargs): Likewise.
> * config/ft32/ft32.cc (ft32_setup_incoming_varargs): Likewise.
> * config/i386/i386.cc (ix86_setup_incoming_varargs): Likewise.
> * config/ia64/ia64.cc (ia64_setup_incoming_varargs): Likewise.
> * config/loongarch/loongarch.cc
> (loongarch_setup_incoming_varargs): Likewise.
> * config/m32r/m32r.cc (m32r_setup_incoming_varargs): Likewise.
> * config/mcore/mcore.cc (mcore_setup_incoming_varargs): Likewise.
> * config/mips/mips.cc (mips_setup_incoming_varargs): Likewise.
> * config/mmix/mmix.cc (mmix_setup_incoming_varargs): Likewise.
> * config/nds32/nds32.cc (nds32_setup_incoming_varargs): Likewise.
> * config/nios2/nios2.cc
