Am Montag, den 02.08.2021, 16:05 +0200 schrieb Martin Uecker:
> > On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin
> > <martin.uec...@med.uni-goettingen.de> wrote:
> > >
> > >
> > > Here is an attempt to fix some old and annoying bugs related
> > > to VLAs and statement expressions. In particulary, this seems
> > > to fix the issues with variably-modified types which are
> > > returned from statement expressions (which works on clang),
> > > but there are still bugs remaining related to structs
> > > with VLA members (which seems to be a FE bug).
> > >
> > > Of course, I might be doing something stupid...
> >
> > How's evaluation order of (f())[g()] defined (with f returning a
> > pointer)?
> > Isn't that just f() + g()*sizeof(int) and thus undefined?
>
> Yes, in C it is
>
> f() + g()
>
> and it is unsequenced. But the order of 'f' and 'g'
> is not relevant here and also the patch does not change
> it (the base expression is gimplified before the index).
>
> Essentially, we have
>
> ({ ... }) + g() * sizeof(X)
>
> where X refers to a declaration in the statement expression.
> Without the patch the size expressions are gimplified before
> the base expression and also before the index expression.
> With the patch the ({ ... }) is gimplified also before the
> size expression.
>
> > If it's undefined then I think the incoming GENERIC is ill-defined.
>
> I think it is OK because the arguments are evaluated
> before the operation. Without the patch, parts of the
> operation (the size expressions) are gimplified before
> the arguments and this seems wrong to me.
If I rewrite the ARRAY_REFs into *(f + g) in the test
cases, they also works with unpatched GCC. So it is really
the incorrect ordering in the gimplification of the
ARRAY_REF which is the problem.
Martin
