From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6986A385F02A; Thu, 25 Aug 2022 19:55:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6986A385F02A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1661457312; bh=Lk6lcoh+tOLJWUnxUdW8AeRs8IPC7YQivWlHL7ih3hs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lbUtGfJ6l2TxmNmGdza0HIwZDvaUd+HWyR2WLn188Be14Pi4vOVv2ZD5/Ao5wkyf4 mP7lrDamvWEP6LhPSoHDh+C2RGDwLASNVCVXV8BfgDNv08fhH4dXtX1noNmQZsYbJS CoDGngTPUPvQORjyzS1ehZ2n2JyE9M/gYewdL7IU= From: "anlauf at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9 Date: Thu, 25 Aug 2022 19:55:12 +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: 12.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: anlauf 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=3D105012 --- Comment #22 from anlauf at gcc dot gnu.org --- (In reply to Richard Biener from comment #20) > With your patch I still see >=20 > __attribute__((fn spec (". r "))) > real(kind=3D8) derfc (real(kind=3D8) & restrict x) > { > integer(kind=3D4) jint; > real(kind=3D8) __result_derfc; >=20 > derfc =3D {CLOBBER}; > calerf_r8 ((real(kind=3D8) *) x, &__result_derfc, &jint); > return __result_derfc; >=20 >=20 > I think the patch wouldn't adjust what the clobber is added to but only > whether it is added, but it seems it fails to catch this case? So maybe > the error is elsewhere. It appears that there are two (only weakly dependent) issues at play here: 1) The patch in comment#18 addresses only the case when the procedures are outside of a module, so that the frontend does not see their interfaces. But since we nowadays have a more global view of all procedures in a fil= e, we are in principle able to exploit things like attributes of the dummie= s. 2) For the handling of clobber for variables that are associated with INTENT(OUT) dummy arguments see also PR41453, which is still open due to some corner cases not yet addressed. The present case, where the actual argument is the function result, shows an anomaly: The clobber is fine if the function has an explicit result clause, while we are confusing symbols (x vs. __result_x) when there is no result clause. See PR41453#c8 for details. The remaining problem from PR41453#c8 is the following code in trans-expr.c= c: (gdb) l 9539,9548 9539 else if (add_clobber && expr->ref =3D=3D NULL) 9540 { 9541 tree clobber; 9542 tree var; 9543 /* FIXME: This fails if var is passed by reference, see PR 9544 41453. */ 9545 var =3D expr->symtree->n.sym->backend_decl; 9546 clobber =3D build_clobber (TREE_TYPE (var)); 9547 gfc_add_modify (&se->pre, var, clobber); 9548 } One needs to understand how to fix up 'var' here for the case at hand. > Note with my testcase from comment#11 fixed as you suggest I don't see a > clobber > at all - I probably simplified too much and gfortran needs the wrapped mo= dule > to see the intent(out). I thought to have fixed that one...=