On Thu, May 19, 2022 at 06:02:43PM +0100, Andrew Stubbs wrote:
> On 19/05/2022 17:00, Jakub Jelinek wrote:
> > Without requires dynamic_allocators, there are various extra restrictions
> > imposed:
> > 1) omp_init_allocator/omp_destroy_allocator may not be called (except for
> > implicit calls to it from uses_allocators) in a target region
>
> I interpreted that more like "omp_init_allocator/... is not required to
> work", as in the set-up steps provided by dynamic_allocators/uses_allocators
> won't be available. Since we don't have any such on/off mode I don't believe
> we need to worry about this (and adding extra logic for this is make-work
> which will not improve the user-experience).
Unfortunately OpenMP as the standard doesn't bother too much with
distinctions that e.g. the C/C++ standards make, whether something makes the
TU invalid or whether something is only invalid at runtime when reaching it.
In any case, I think it would be nice if we diagnosed such uses, doesn't
need to be an error, warning would be fine, but help users write portable
code, either that they requires dynamic_allocators, or don't and limit
themselves to what the standard says should be used in that case.
I guess a warning might be better, because we really don't know if it will
be actually called at runtime or not from the target region.
> > 2) omp_alloc etc. can't be called with omp_null_allocator and the argument
> > has to be a constant expression for a predefined memory allocator
> > (that is also mentioned on uses_allocators, though that doesn't have to
> > be visible in the source because it could be lexically included in
> > a target construct's body)
>
> Again, does a conforming implementation reject this, or is it merely not
> required to accept it?
I think it is another fuzzy area, but again it would be nice to at least
get warnings.
Jakub
