From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1D5893858D33; Wed, 21 Feb 2024 01:31:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1D5893858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708479074; bh=hHLX7kp9heYIZC5Ab7+D58fialXa2VC0WfN/8rubyW4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ePpPVu5qZG8lBduRyks72506VN3BxIUUZG2HP+a0MUtFxaoAAx/5kxGUZ64i9S+yr ApUyKixkAhwU0ArclgL4AwGRh/wLOG4qyUgPe8nzeFGLIgArd3sBl9JCgCC7JolSlZ mn3us+SB8o3mYVTGITlc7uSeFoZi0mceS2aSSQKc= From: "kargl at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array Date: Wed, 21 Feb 2024 01:31:13 +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: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kargl 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: priority 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=3D114024 kargl at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P4 --- Comment #2 from kargl at gcc dot gnu.org --- This is ugly. Essentially, the translation of an allocate statement is mot prepared to have a complex-part-ref as the source expression. For this code program foo implicit none complex :: cmp(3) real, allocatable :: xx(:), yy(:), zz(:) cmp =3D (3.45,6.78) allocate (xx, source =3D cmp%re) ! ICE allocate (yy, source =3D cmp(1:3)%re) ! ICE allocate (zz, source =3D (cmp%re)) print *, xx print *, yy print *, zz end The lines marked with ICE will cause gfortran to, well, ICE. The following patch cures the issues by impose a set of parentheses=20 about the source expression. There is likely a better way. diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc index 5247d3d39d7..6ff3f12d7ed 100644 --- a/gcc/fortran/trans-stmt.cc +++ b/gcc/fortran/trans-stmt.cc @@ -6355,8 +6355,24 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist *omp_allocate) vtab_needed =3D (al->expr->ts.type =3D=3D BT_CLASS); gfc_init_se (&se, NULL); - /* When expr3 is a variable, i.e., a very simple expression, - then convert it once here. */ + + /* When expr3 is a variable, i.e., a very simple expression, then + convert it once here. Note, if one has source =3D z%re or z%im,=20 + then things can go sideways with the complex-part-ref, so wrap + the entity in parentheses to force evaluation of an expression. + That is, the else-branch of the ensuing if-else-stmt is entered. = */ + + if (code->expr3->ref + && ((code->expr3->ref->u.i =3D=3D INQUIRY_RE + || code->expr3->ref->u.i =3D=3D INQUIRY_IM) + || (code->expr3->ref->type =3D=3D REF_ARRAY + && code->expr3->ref->u.ar.type =3D=3D AR_SECTION))) + { + gfc_expr *etmp =3D gfc_get_parentheses (code->expr3); + code->expr3 =3D gfc_copy_expr (etmp); + gfc_free_expr (etmp); + } + if (code->expr3->expr_type =3D=3D EXPR_VARIABLE || code->expr3->expr_type =3D=3D EXPR_ARRAY || code->expr3->expr_type =3D=3D EXPR_CONSTANT)=