[Patch][v2] OpenMP/Fortran: Fix loop-iter var privatization with !$OMP LOOP [PR108512]

[Tobias Burnus]

Updated version attached.

On 31.01.23 12:20, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Jan 24, 2023 at 04:24:07PM +0100, Tobias Burnus wrote:
>> +      if (code->op == EXEC_OMP_LOOP)
>> +    ;  /* Already rejected in resolve_omp_clauses.  */
> I don't understand why is this needed.  Sure, the vast majority of
> constructs don't allow reduction(inscan, ...), do we need to list them all?

I think using the same != condition as in resolve_omp_clauses would be
better. The messages inside this procedure come earlier than the ones in
resolve_omp_clauses. Thus, they cannot be silenced there.

However, while I did try this, preventing some odd error messages, I
have now removed it again. – It is never quite clear when it is better
to have multiple error messages and when suppressing some is better.

  * * *

For more on 'inscan' and combined constructs (mainly with target, an
OpenMP 5.1 feature), see the newly filed https://gcc.gnu.org/PR108749

>> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
>> index 94213cd3cd4..bd2a749776d 100644
>> --- a/gcc/fortran/resolve.cc
>> +++ b/gcc/fortran/resolve.cc
>> @@ -11950,6 +11950,7 @@ gfc_resolve_code (gfc_code *code, gfc_namespace *ns)
>>          case EXEC_OMP_DISTRIBUTE_SIMD:
>>          case EXEC_OMP_DO:
>>          case EXEC_OMP_DO_SIMD:
>> +        case EXEC_OMP_LOOP:
>>          case EXEC_OMP_SIMD:
>>          case EXEC_OMP_TARGET_SIMD:
>>            gfc_resolve_omp_do_blocks (code, ns);
> I'm afraid this is needed but insufficient.
> I think
>              case EXEC_OMP_MASKED_TASKLOOP:
>              case EXEC_OMP_MASKED_TASKLOOP_SIMD:
>              case EXEC_OMP_MASTER_TASKLOOP:
>              case EXEC_OMP_MASTER_TASKLOOP_SIMD:
>           case EXEC_OMP_PARALLEL_LOOP:
>           case EXEC_OMP_TARGET_PARALLEL_LOOP:
>           case EXEC_OMP_TARGET_TEAMS_LOOP:
>           case EXEC_OMP_TARGET_SIMD:
>           case EXEC_OMP_TEAMS_LOOP:
> should be in the list above (of course alphabetically sorted in between the
> others)
>             gfc_resolve_omp_parallel_blocks (code, ns);

I think 'TARGET_SIMD' shouldn't be resolved though parallel blocks but
can call directly call gfc_resolve_omp_do_blocks (as
currently/previously implemented). The masked version were already
handled inside gfc_resolve_omp_parallel_blocks but missing in
gfc_resolve_code, while the 'loop' ones had to be added to both.

(I did not extend the testcase, but I updated two to add additional
dg-error to the same line.)

Thanks for the comments. Any further suggestions?

Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-omp-parallel-loop-v2.diff
Type: text/x-patch
Size: 11733 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20230210/5c522797/attachment.bin>