On Thu, Oct 20, 2022 at 1:54 AM Joseph Myers <jos...@codesourcery.com> wrote: > > C2x allows variable-argument functions declared with (...) as parameters - > no named arguments - as in C++. It *also* allows such functions to access > their parameters, unlike C++, by relaxing the requirements on va_start so > it no longer needs to be passed the name of the last named parameter. > > My assumption is that such functions should thus use the ABI for > variable-argument functions, to the extent that's different from that for > other functions. The main implementation issue I see is that GCC's > internal representation for function types can't actually distinguish the > (...) type from an unprototyped function - C++ functions with (...) > arguments are treated by the middle end and back ends as unprototyped. > (This probably works sufficiently well in ABI terms when the function > can't actually use its arguments. Back ends may well call what they think > are unprototyped functions in a way compatible with variadic callees > anyway, for compatibility with pre-standard C code that calls e.g. printf > without a prototype, even though standard C has never allowed calling > variable-argument functions without a prototype.) > > So there are a few questions here for implementing this C2x feature: > > 1. How should (...) be represented differently from unprototyped functions > so that stdarg_p and prototype_p handle it properly? Should I add a new > language-independent type flag (there are plenty spare) to use for this?
I'd say unprototyped should stay with a NULL TYPE_ARG_TYPES but a varargs function might change to have a TREE_LIST with a NULL type as the trailing element? Not sure if we want to change this also for varargs functions with actual arguments. If we want to go down the route with a flag on the function type then I'd rather flag the unprototyped case and leave varargs without any actual arguments as NULL TYPE_ARG_TYPES? > 2. Does anyone see any likely ABI or back end issues from allowing > single-argument calls to __builtin_va_start to access the arguments to > such a function? (I'd propose to redefine va_start in stdarg.h to use a > single-argument call, discarding any subsequent arguments, only for C2x.) > > 3. Should the C++ front end be changed to mark (...) functions in whatever > way is chosen for question 1 above, so that they start using the > appropriate ABI (and, in particular, calls between C and C++, where a C > implementation of such a function might use the arguments, work properly)? > Or would there be problems with compatibility with existing callers or > callees assuming the unprototyped function ABI? > > -- > Joseph S. Myers > jos...@codesourcery.com
