On Tue, Mar 16, 2021 at 10:36:35AM +0100, Richard Biener wrote:
> On Tue, Mar 16, 2021 at 10:29 AM Jakub Jelinek <ja...@redhat.com> wrote:
> >
> > On Tue, Mar 16, 2021 at 09:46:33AM +0100, Richard Biener wrote:
> > > > shows we have an interface problem here -- we shouldn't need something
> > > > this
> > > > convoluted to walk through an argument list. But that's not your
> > > > problem
> > > > or a problem with the patch.
> > >
> > > The caller side should IMHO always look at TYPE_ARG_TYPES since
> > > that's what determines the ABI. But IIRC there were problems in the past
> > > that TYPE_ARG_TYPES might be NULL but DECL_ARGUMENTS not?!
> >
> > Yes, for the K&R definitions
> > #pragma omp declare simd
> > int
> > foo (a, b, c)
> > int a, b, c;
> > {
> > return a + b + c;
> > }
>
> The C frontend could still populate TYPE_ARG_TYPES here, OTOH IIRC
> K&R definitions work like unprototyped functions on the caller side, thus
> having varargs argument passing semantics?
Not varargs semantics, but unprototyped function semantics, i.e. the same
as for
int foo ();
Which means callers can pass anything, but it is not ..., i.e. callee can't
use va_start/va_end/va_arg and the ... calling conventions are not in place
(e.g. the passing of arguments in two places on some targets, or the
extra %rax on x86_64 etc.).
Jakub
