From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 84B6E3854833; Mon, 20 Mar 2023 17:21:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 84B6E3854833 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1679332862; bh=GKybbOzWoprRBzWdShSKWL1Io1f3sr7lRftaHxX9WcU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jfLBWBh+STA3JJbvq7LrMUQ6N8mBjyzlC4RXkPqyXGZqszrD53rFXnxPPiTkBHdXR kVb7SMKfouTF5++KpD7QHp4f6t1+2eeMOR+gW27/1FCT+/pGEinazNdo7z6m9JWfVg kXvfJkjDj9saRJoz0dV2SOR40NlV6vh/MDNNNzYM= From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables Date: Mon, 20 Mar 2023 17:21:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109209 --- Comment #12 from Tobias Burnus --- I bet that's due to the finalization commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee but I have not verified. (In reply to J=C3=BCrgen 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 genera= ted > code violating the standard? I think the code is OK as the constraint is not violated by the user code b= ut 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 =E2=86=91] The following fixes it, but ... [TODO =E2=86=93] ... 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 =3D true; + this_code->expr2->generated =3D true; * * *=20 > > 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.=