From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9E0293858C62; Fri, 20 Jan 2023 18:03:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E0293858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674237834; bh=cDpdQ6pKFg2Vu3pWB3yeI4xdF8HfIHEQkCerFClVkF0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=auHVki78NP7cIsqvAsw0CHzu3wtek5MurQcjIPpxikxq45reEsWA0G9TxjepThHZU QusDiyoBwR6wo08ySL0K//awzSu7WZbNMmQJF1osJQrhr/LjGWZ3pZCNvodE7vtK9i MjzN/Lggc83SV6ZFt3GYX1WS0Z5l7Sx3UDfzg0x0= From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2 Date: Fri, 20 Jan 2023 18:03:53 +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: ice-on-invalid-code, openmp 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: 12.3 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=3D108450 --- Comment #2 from Tobias Burnus --- Interestingly, it is resolved twice. First for: (gdb) p gfc_debug_expr(e) maxloc[((p:a) (mask =3D p:l))] via resolve_all_program_units =E2=86=92 gfc_resolve =E2=86=92 gfc_resolve =E2= =86=92 resolve_codes =E2=86=92 gfc_resolve_code =E2=86=92 gfc_resolve_blocks =E2=86=92 gfc_resolve_code = =E2=86=92 gfc_resolve_expr And then via: ... =E2=86=92 resolve_omp_atomic =E2=86=92 gfc_resolve_expr The problem is that in the latter case, the 'e' is now: maxloc[((p:a(FULL)) (mask =3D p:l) (.false.))] and the unprefixed .false. seems to cause the problems. The intrinsic uses: RESULT =3D MAXLOC(ARRAY, DIM [, MASK] [,KIND] [,BACK]) RESULT =3D MAXLOC(ARRAY [, MASK] [,KIND] [,BACK]) During the first call to check_specific, maxloc[((p:a(FULL)) (mask =3D p:l))] is turned into maxloc[((p:a(FULL)) ((arg not-present)) (mask =3D p:l) ((arg not-present)) ((arg not-present)))] via 4774 if (!sort_actual (specific->name, ap, specific->formal, &expr->where)) The null-args are later removed via 'remove_nullargs (ap);' * * * Thus, it looks as if resolving the RHS expression twice is wrong.=