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...

  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: link
Be 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).