Hi Jakub,
On 21.02.22 18:47, Jakub Jelinek wrote:
Where ME is involved is
!$omp requires atomic_default_mem_order(whatever) vs.
!$omp declare variant ...atomic_default_mem_order(whatever).
Ups, missed that case. (Also because there wasn't 'declare variant' when
implementing 'requires' in Fortr
On Mon, Feb 21, 2022 at 06:02:06PM +0100, Tobias Burnus wrote:
> I wonder whether there is a real problem in terms of the ME, but maybe
> there is.
>
> For atomic_default_mem_order: That's purely handle by the FEs by
> setting the default – and just using it when parsing the 'atomic'
> directive,
Hi Jakub, hi Abid, hi all,
On 21.02.22 16:50, Jakub Jelinek via Fortran wrote:
The thing is, omp_requires_mask was added for C/C++ from the C/C++ notion of
translation units (and a question is how does that cope with C++20 modules),
with the assumption that once certain #pragma omp requires is s
On Mon, Feb 21, 2022 at 02:24:40PM +, Hafiz Abid Qadeer wrote:
> This patch fixes an issue that although gfortran accepts
> 'requires dynamic_allocators', it does not set the omp_requires_mask
> accordingly.
>
> gcc/fortran/ChangeLog:
>
> * parse.cc (gfc_parse_file): Set OMP_REQUIRES_DY
This patch fixes an issue that although gfortran accepts
'requires dynamic_allocators', it does not set the omp_requires_mask
accordingly.
gcc/fortran/ChangeLog:
* parse.cc (gfc_parse_file): Set OMP_REQUIRES_DYNAMIC_ALLOCATORS
bit in omp_requires_mask.
---
gcc/fortran/parse.cc |
