public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "anlauf at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-105012-4-G9pxW7xM24@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-105012-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 --- Comment #22 from anlauf at gcc dot gnu.org --- (In reply to Richard Biener from comment #20) > With your patch I still see > > __attribute__((fn spec (". r "))) > real(kind=8) derfc (real(kind=8) & restrict x) > { > integer(kind=4) jint; > real(kind=8) __result_derfc; > > derfc = {CLOBBER}; > calerf_r8 ((real(kind=8) *) x, &__result_derfc, &jint); > return __result_derfc; > > > 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 file, we are in principle able to exploit things like attributes of the dummies. 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.cc: (gdb) l 9539,9548 9539 else if (add_clobber && expr->ref == NULL) 9540 { 9541 tree clobber; 9542 tree var; 9543 /* FIXME: This fails if var is passed by reference, see PR 9544 41453. */ 9545 var = expr->symtree->n.sym->backend_decl; 9546 clobber = 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 module > to see the intent(out). I thought to have fixed that one...
next prev parent reply other threads:[~2022-08-25 19:55 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-22 8:54 [Bug lto/105012] New: [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking tnfchris at gcc dot gnu.org 2022-03-22 9:36 ` [Bug lto/105012] " marxin at gcc dot gnu.org 2022-03-22 10:21 ` rguenth at gcc dot gnu.org 2022-03-22 10:23 ` rguenth at gcc dot gnu.org 2022-03-22 10:37 ` marxin at gcc dot gnu.org 2022-03-22 10:52 ` rguenth at gcc dot gnu.org 2022-03-22 10:53 ` [Bug lto/105012] [12 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9 marxin at gcc dot gnu.org 2022-03-22 10:58 ` marxin at gcc dot gnu.org 2022-03-22 11:06 ` [Bug fortran/105012] " rguenth at gcc dot gnu.org 2022-03-22 11:09 ` marxin at gcc dot gnu.org 2022-03-22 11:11 ` rguenth at gcc dot gnu.org 2022-03-22 11:18 ` rguenth at gcc dot gnu.org 2022-03-22 11:20 ` rguenth at gcc dot gnu.org 2022-03-22 11:31 ` rguenth at gcc dot gnu.org 2022-03-22 13:05 ` cvs-commit at gcc dot gnu.org 2022-03-22 13:07 ` rguenth at gcc dot gnu.org 2022-05-06 8:33 ` [Bug fortran/105012] [12/13 " jakub at gcc dot gnu.org 2022-08-24 19:36 ` anlauf at gcc dot gnu.org 2022-08-24 20:34 ` anlauf at gcc dot gnu.org 2022-08-25 6:13 ` rguenth at gcc dot gnu.org 2022-08-25 6:18 ` rguenth at gcc dot gnu.org 2022-08-25 19:50 ` mikael at gcc dot gnu.org 2022-08-25 19:55 ` anlauf at gcc dot gnu.org [this message] 2022-08-25 19:57 ` anlauf at gcc dot gnu.org 2022-08-25 20:06 ` mikael at gcc dot gnu.org 2022-08-25 20:30 ` anlauf at gcc dot gnu.org 2022-08-25 20:40 ` mikael at gcc dot gnu.org 2022-08-25 20:47 ` anlauf at gcc dot gnu.org 2022-08-25 21:19 ` mikael at gcc dot gnu.org 2022-08-25 21:31 ` anlauf at gcc dot gnu.org 2022-08-28 10:27 ` mikael at gcc dot gnu.org 2022-09-02 19:04 ` mikael at gcc dot gnu.org 2022-09-25 12:48 ` cvs-commit at gcc dot gnu.org 2022-09-25 12:48 ` cvs-commit at gcc dot gnu.org 2022-10-10 20:04 ` cvs-commit at gcc dot gnu.org 2022-10-10 20:53 ` cvs-commit at gcc dot gnu.org 2022-10-12 12:34 ` cvs-commit at gcc dot gnu.org 2022-10-12 12:42 ` mikael at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-105012-4-G9pxW7xM24@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).