[PATCH] OpenMP/Fortran: Rebind labels after metadirective body [PR122369]

Tobias Burnus tburnus@baylibre.com
Fri Oct 31 17:41:15 GMT 2025


Hi PA,

Paul-Antoine Arras wrote:
> On 29/10/2025 18:44, Tobias Burnus wrote:
>> This does not seem to work in general:
>>
>> integer :: cnt, x
>>
>> cnt = 0
>> !$omp begin metadirective when(user={condition(cnt > 0)} : parallel)
>>    x = 5
>> !$omp end metadirective
>> 1234 format("Hello")
>> write(*,1234)
>>
>> !$omp begin metadirective when(user={condition(x > 0)} : parallel)
>>    x = 5
>> !$omp end metadirective
>> 4567 print *, 'hello', cnt
>> cnt = cnt + 1
>> if (cnt < 2) goto 4567
>> end
>
> Here is a revamped version of the patch that should handle properly 
> more cases.

There is still a warning with -Wall:

Warning: Label 4567 at (1) defined but not used [-Wunused-label]
Warning: Label 1234 at (1) defined but not used [-Wunused-label]

That's handled by gfc_reference_st_label, but the question is:
why doesn't this work here?

* * *

It seems as if this is due parsing the body multiple times. I see
in the first call to gfc_rebind_label:

(gdb) p label->ns->st_labels
$20 = (gfc_st_label *) 0x3752060
(gdb) p *label->ns->st_labels
$17 = {priority = 32547, left = 0x3757d00, right = 0x0, value = 1234, defined = ST_LABEL_FORMAT, referenced = ST_LABEL_UNKNOWN, format = 0x3757a30, backend_decl = 0x0, where = {nextc = 0x37402f0, u = {lb = 0x37402c0, location = 57934528}}, ns = 0x3750520, omp_region = 1}
(gdb) p *label->ns->st_labels->left
$18 = {priority = 20296, left = 0x0, right = 0x0, value = 1234, defined = ST_LABEL_FORMAT, referenced = ST_LABEL_UNKNOWN, format = 0x3757e70, backend_decl = 0x0, where = {nextc = 0x37402f0, u = {lb = 0x37402c0, location = 57934528}}, ns = 0x3750520, omp_region = 2}

The call is:

gfc_rebind_label (label=0x3757d00, new_omp_region=new_omp_region@entry=0)

Thus, only the st_labels->left is fixed, st_labels remains (unused) in
the wrong scope.

* * *

This is fixed if you move the label handling a few lines up
above the '}' of the 'while (variant)' loop.

* * *
* * *

However, we still run into the same issue that I alluded
in PR122508. We need the use the following value for
omp_region:

1111 FORMAT("outside") ! → omp_region = 0
!$omp metadirective when(... : parallel)
   2222 FORMAT("outer") ! → omp_region = 1 (parallel), 2 (nothing)
   !$omp metadirective when(... : parallel)
     3333 FORMAT("inner")
     ! → omp_region = 3 (parallel,parallel)
     ! → omp_region = 4 (parallel,nothing)
     ! → omp_region = 5 (nothing,parallel)
     ! → omp_region = 6 (nothing,nothing)
   !$omp end parallel
   4444 FORMAT("outer 2") ! → omp_region = 1 (parallel), 2 (nothing)
!$omp end parallel
5555 FORMAT("outside 2") ! → omp_region = 0

Currently, we get (without -Wall or with moving it
to 'variant'):

     9 | write(*,1234)
       |             1
Error: FORMAT label 1234 at (1) not defined with:

For:

integer :: cnt, x
cnt = 0
!$omp begin metadirective when(user={condition(cnt > 0)} : parallel)
   !$omp begin metadirective when(user={condition(cnt > 0)} : parallel)
     x = 5
   !$omp end metadirective
   1234 format("Hello")
   write(*,1234)
!$omp end metadirective
end

And likewise for the second testcase in the file,
just with 4 times:

Error: Label 4567 referenced at (1) is never defined

* * *

BTW: Can you add -Wall or -Wunused-label to all testcases?

* * *

>> 1345 format("The count is ", g0)
...
>> !$omp begin metadirective when(user={condition(cnt > 0)} : parallel)
>>    write(*,1345) cnt
>> !$omp end metadirective
>> end
> I have now created a new PR for that: https://gcc.gnu.org/PR122508.

I have attached a draft patch. For the simple case of
a single metadirective it works fine. - It fails if
one nests them.

Currently we have only the latest used label available -
but we need at least the last parent one for this use
and for PR122508, we need to find all previous ones.

Thus, maybe something like:
   vec<int> gfc_omp_metadirective_region_count
or
   std::vector<int> gfc_omp_metadirective_region_count
where we push/pop the current count value.

And a separate variable which keeps track of the used
version.

* * *

BTW: Please consider to handle PR122508 as part of this
issue; it seems as if doing so using a stack as mentioned
above + tweaking the existing patch to PR122508 (+ adding
the two tests) should be straight forward.

Sorry that I keep finding issues :-/

Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20251031/cd536a49/attachment-0001.htm>


More information about the Fortran mailing list