https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62131
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |openmp, rejects-valid
CC| |burnus at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
Target Milestone|--- |4.9.3
Summary|Openmp Regression 4.9.1 : |[4.9.1 Regression] OpenMP:
|Subobject of an allocatable |Subobject of an allocatable
|array not allowed in OMP |array not allowed in OMP
|ATOMIC |ATOMIC
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
To summon up: It's not about "!$OMP ATOMIC with ALLOCATABLE variable at (1)"
being the wrong check - it's about having a warning for a nonallocatable
variable.
The point is: Even if "a" is allocatable, "a(1,2)" is not allocatable - and for
"dt%b" it would depend on "b" and not on "a".
I think the OpenMP constraint is there to avoid that (re)allocation on
assignment gets triggered for atomic assignments.
The current code, cf. line 2744 of the gcc/fortran/openmp.c, uses:
var = code->expr1->symtree->n.sym;
...
if (var->attr.allocatable)
I think the simplest would be to use:
if (gfc_expr_attr (code->expr1).allocatable))
However, there might be other spots in the code where using "var" looks at the
wrong thing for component references (like: "var%comp"). For instance,
|| expr2_tmp->symtree->n.sym == var)
might reject "var%b = var%a" code - which may or may not be intended.
