On Tue, Mar 16, 2021 at 10:40 AM Jakub Jelinek <ja...@redhat.com> wrote:
>
> 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.).
Right, so for the caller side looking at DECL_ARGUMENTS is wrong as well
then, the actual argument list is what matters for the used ABI.
Anyway, I suppose the hook may just give up for calls to unprototyped functions?
Richard.
>
> Jakub
>
