On Thu, May 05, 2022 at 12:46:29PM +0100, Julian Brown wrote:
> All the above (at least) has been done as part of the patch series
> posted here:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591973.html
Ah, ok, so is this patch superseded by that series, or do you want to apply
it just to be removed again?
> > At least for the C FE maybe we'll
> > need to arrange for less folding to be done because C still folds too
> > much stuff prematurely. Then when finishing clauses verify that
> > OMP_ARRAY_SECTION trees appear only where we allow them and not
> > elsewhere (say foo (1, 2, 3)[:36]
> > would be ok if foo returns a pointer, but
> > foo (ptr[0:13], 2, 3)
> > would not) and then need to differentiate between the cases listed in
> > the standard which we handle for each . -> [idx] when starting from a
> > var (in such a case I vaguely recall there are rules for pointer
> > attachments etc.) or other arbitrary expressions (in that case we
> > just evaluate those expressions and e.g. in the foo (1, 2, 3)[:36]
> > case basically do tmp = foo (1, 2, 3);
> > and mapping of tmp[:36].
>
> ...which also changes/refactors quite a lot regarding how lowering
> clauses into mapping nodes works (the "address inspector" bits).
> "Weird" cases like mapping the return value from functions doesn't
> necessarily DTRT yet -- it wasn't entirely clear how that should/could
> work, I don't think.
I vaguely remember that the ./-/[] handling applies only when it starts
from a variable and as soon as one triggers something else, perhaps
including just *& or similar stuff then only the final lvalue is mapped and
nothing else, but dunno if it is from just discussions about the topic or
what is actually written in the spec, will need to look it up.
Jakub
