Am Dienstag, den 03.08.2021, 11:26 +0200 schrieb Richard Biener:
> On Tue, Aug 3, 2021 at 10:28 AM Martin Uecker <muec...@gwdg.de>
> wrote:
> >
> > Hi
> > Am Dienstag, den 03.08.2021, 10:10 +0200 schrieb Richard Biener:
> > > On Tue, Aug 3, 2021 at 7:32 AM Martin Uecker <muec...@gwdg.de>
> > > wrote:
> > > >
> > > > (resending from a different account, as emails seem to do not
> > > > go out from my other account at this time)
> > > >
> > > > 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.
> > >
> > > But you said the evaluation order is undefined.
> >
> > The evaluation order of the two arguments (base
> > and index) is undefined. But the operation itself has
> > to happen after the arguments are evaluated like
> > the call to a is sequenced before f and g:
> >
> > a(f(), g())
> >
> >
> > Computing the correct step size in the pointer
> > arithmetic is part of the operation itself and not
> > part of the evaluation of the arguments.
> >
> > The problem here is that this part of the operation
> > is done before the arguments are evaluated, which
> > is a compiler bug.
>
> Yes, but the bug is IMHO in the C frontend which inserts the
> DECL_EXPR at a wrong spot, not making sure it is evaluated before it
> is used. Working around this deficiency in the gimplifier sounds
> incorrect.
The size if part of the type of the value which is
returned from the compound expression.
So that there is a declaration involved was maybe
misleading in my example and explanation.
So let me try again:
The size *expression* needs be be computed inside the
statement expression (also because of side effects)
and then the result of this computation needs to
returned together (as part of) the value returned
by the statement expression.
But the compilers tries to gimplify the size expression
that comes with the value already before the statement
expression is evaluated. This can not work, no matter
what the front end does.
>
> Does the same issue arise with writing the testcases as
>
> ({ ... }) + i;
>
> ? How can we fix it then if you also need to support
>
> i + ({ ...});
>
>
> ?
This already works correctly. I assume that here
the gimplifcation is already done in the right
order.
But ARRAY_REF is handled as a separate case and
there it is wrong.
Martin
>
> > > So IMHO the GENERIC is undefined in evaluating the size of sth
> > > that's not live?
> > >
> > > That said, given the statement expression
> > > result undergoes array to pointer decay doesn't this pointer
> > > refer to an object that ended its lifetime?
> > > "In a statement expression, any temporaries created within a
> > > statement are destroyed at that statement's end."
> > > That is, don't the testcases all invoke undefined behavior at
> > > runtime?
> >
> > This is true for one of the test cases (where not having
> > an ICE is then
> > a QoI issue), but not for the others
> > where the object is allocated by
> > malloc and a pointer
> > to the object is returned from the statement
> > expression.
> > This is supposed to work.
> >
> >
> > Martin
> >
> >
> >
