https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> --- I bet that's due to the finalization commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee but I have not verified. (In reply to Jürgen Reuter from comment #10) > Thanks for checking, Tobias. Are you saying that the code violates the > standard, or the code generation after parsing by gcc/gfortran has generated > code violating the standard? I think the code is OK as the constraint is not violated by the user code but only by the code generated by the compiler internally from the user code. However, I have only very narrowly looked at the gcc/fortran/*.cc code and not tried to understand the Fortran code and what makes sense. [TODO ↑] The following fixes it, but ... [TODO ↓] ... I have not come to a conclusion whether the generated tree code (-fdump-tree-original) is correct with regards to (re)allocation on assignment or memory freeing. diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index 9bab2c40ead..8d4e276d8a3 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -2567,0 +2568,3 @@ typedef struct gfc_expr + /* Set if the component assignment was generated by the compiler. */ + unsigned int generated : 1; + diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 1d973d12ff1..df3979ca8f4 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -5456 +5456,2 @@ gfc_resolve_ref (gfc_expr *expr) - if (current_part_dimension || seen_part_dimension) + if ((current_part_dimension || seen_part_dimension) + && !expr->generated) @@ -5518 +5519,2 @@ gfc_resolve_ref (gfc_expr *expr) - && seen_part_dimension) + && seen_part_dimension + && !expr->generated) @@ -11370,0 +11373,2 @@ build_assignment (gfc_exec_op op, gfc_expr *expr1, gfc_expr *expr2, + this_code->expr1->generated = true; + this_code->expr2->generated = true; * * * > > module subroutine t3_set_expand (res_set) > Actually, the 'module subroutine' here needs to be just 'subroutine'. > gfortran accepts this, nagfor doesn't. I filed PR 109218 for this issue.
