On Tue, Sep 07, 2021 at 01:22:43PM +0200, Tobias Burnus wrote:
> On 07.09.21 12:49, Jakub Jelinek wrote:
> > On Tue, Sep 07, 2021 at 12:39:01PM +0200, Tobias Burnus wrote:
> > > +@item @code{declare variant} directive @tab P @tab Only C and C++
> > Even for C/C++, we don't handle the simd stuff there (where we should be
> > expecting a different function types in those cases, ones following the
> > declare simd ABIs). So, essentially it is correct only on
> > non-x86/non-aarch64, because other arches don't have their declare simd
> > ABIs.
> I now use: ", simd taits not handled".
s/taits/traits/ and I'd add /handled/& correctly/
> > > +@item C/C++'s lvalue expressions in @code{to}, @code{from}, @code{depend}
> > > + and @code{map} clause @tab Y @tab
> > I think this is not implemented yet, at least not in trunk.
> > We don't allow map(to:foo(234)[:32]) or map(to:bar()->x->y[5].z[3]) etc.
>
> I somehow had the impression that I saw lvalues for 'depend', but while
> they are more complicated, I think I did not see f()[1] etc. – For
> mapping, I did see patches implementing stuff like 'z->x->y[5]' (which
> are pending review) but I think that even those did not use a function
> call on the left. Thus, a simple pilot error.
We do indeed support it for depend (and affinity), just don't support in
the lvalue case array sections, so perhaps split the
depend case from the other clauses. The depend parsing tries to parse it
as the rigid varname followed by optional . field or array section and if
that fails, parses it as an expression, verifies it is lvalue and just
uses the address of that lvalue as the depend address.
While for map/to/from, I think what we need to do is make the OpenMP array
section a new tree code (perhaps C/C++ FE only), which is not recognized by
default, only when certain flag is set, set that flag while parsing
map/to/from/depend/affinity operands and clear afterwards, use normal
expression parsing and then verify after parsing that it is only used in the
spots where it can be used.
> I have now added "Stub only" to both the 'close' modifier and, for
> completeness, to the the 'affinity' clause. – I think both are
> relatively boring; possibly, with unified shared memory or (for
> affinity) real NUMA memory, they become a tad more useful.
True.
Jakub
