You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases, when privatizing a threadprivate common block, the
original symbol will correspond to the common block, instead of
its threadprivate version. This can happen, for instance, with a
common block, declared in a separate module, used by a parent
procedure and privatized in its child procedure. In this case,
symbol lookup won't find a symbol in the parent procedure, but
only in the module where the common block was defined.
Fixesllvm#65028
In some cases, when privatizing a threadprivate common block, the
original symbol will correspond to the common block, instead of
its threadprivate version. This can happen, for instance, with a
common block, declared in a separate module, used by a parent
procedure and privatized in its child procedure. In this case,
symbol lookup won't find a symbol in the parent procedure, but
only in the module where the common block was defined.
Fixes#65028
This is an issue from Fujitsu testsuite.
Compilation crashes when we use
copyin
clause in internal subprogram. It works fine when we removecopyin (k1)
from the program.The program and backtrace are as follows.
snggy270.f90
Gfortran and ifort can compile the program. The output executable files also go well.
The text was updated successfully, but these errors were encountered: