https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #3)
> Any update on the failing target1.f90 test-case?
Not yet. What needs to be done is to mark loop variables as "private" – and
attach this to the proper OpenMP directive; with "teams", "distribute" and
multiple loops this can get rather complex.
The middle end does this for "for" loops – but the Fortran FE *only* generates
them for OpenMP loops – in particular for "simd". For normal Fortran loops, the
ME does not recognize the loop variable.
Hence, the complex algorithm of "2.19.1.1 Variables Referenced in a Construct"
has to be implemented – i.e. skipping the private for those which already have
firstprivate/lastprivate/private and attaching it to the correct directive.
The ICE occurs if the private is attached to the wrong OpenMP directive which
the ME then confuses.
There can be a large number of directives combined (see target1.f90):
!$omp target teams distribute parallel do …
do i = 1, 10
do j = 1, 10
with some clauses like collapse(1) or collapse(2) or …
The FE adds the "private" in gfc_resolve_do_iterator – and later in
gfc_trans_omp_do (only for the OpenMP loops, there can be "normal" loops in
between) and for combined directives above, they get split in
gfc_split_omp_clauses – hence, the predetermined …private has end up on the
right directive.
I think adding 'private' only for non-OpenMP will avoid some split issues – but
to do this, one has to evaluate 'collapse' etc. to know whether a loop becomes
a ME-treated 'for' loop or not.
And for nested omp directives, one has to attach the directive to the right
directive.
Example:
!$omp teams
!$omp distribute
!$omp do
do i = 1,n ! Omp loop, handled by ME
do j = 1, m ! Fortran loop, unless collapse(2)
…
do i = 1,n … ! Fortran loop – not 'omp do' but inside 'omp distribute'
To which directive should "private(i)" and private(j) be attached to? How
differs this if there is a private/lastprivate/firstprivate on any of the
directives?
(The patch which causes this fail fixed other ICEs with another test case, but
caused the target1.f90 fail. Thus, by undoing/doing those bits of r11-349 one
can toggle between ICEs in the same ME function.)
