From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9E9AD3858417; Mon, 20 Mar 2023 16:48:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E9AD3858417 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1679330887; bh=6ZkMHRZz4pXGh3462lBC7lhzl1lZupoxfLYL/eYjkQk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DrMhObTV0dhUqLzX5W+clE/S6UFz0f5e/kLChqGkWLitQdJvxpphvJC8yAbBxPwca lQcw8p2DU6ijLFZuhc7dMqNn0LWn3ZK//P4Hrx2uw0AbNgHSgTINSUGu5InD1rCtac LpWHjTz/MKLowkriMEHC7eI/5DGzX9fWJNq40/Rw= 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 16:48:06 +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: UNCONFIRMED 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 #8 from Tobias Burnus --- The debugger shows for the example in comment 4 for the line 69 | history_new(1:s) =3D res_set%history(1:s) the following expression: (gdb) p gfc_debug_expr(expr) t3_set_expand:history_new(1:__convert_i4_i8[[((t3_set_expand:s))]]) % resonances(FULL) That's F03:C614 - or in F2018: C919 (R911) There shall not be more than one part-ref with nonzero rank. A part-name to the right of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute. For the 'expr' shown in the debugger, that's violated as 'resonances' is allocatable. The 'expr' shown above is generated via generate_component_assignments -> gfc_resolve_expr -> resolve_variable -> gfc_resolve_ref where generate_component_assignments's gfc_debug_code(*code) is ASSIGN t3_set_expand:history_new(1:__convert_i4_i8[[((t3_set_expand:s))]]) t3_set_expand:res_set % history(1:__convert_i4_i8[[((t3_set_expand:s))]= ]) which matches the user code and looks fine. (BTW: We should also check whether there is now an issue with generating redundant (re)allocate on assignment code in trans*.cc.)=