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