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: Wed, 24 Aug 2022 19:36:30 +0000 [thread overview] Message-ID: <bug-105012-4-2db7RHVDRZ@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 #17 from anlauf at gcc dot gnu.org --- (In reply to Richard Biener from comment #11) > (In reply to Richard Biener from comment #10) > > likely triggered by the INTENT(out), it looks like gfortran fails to properly > > name-lookup a variable of the same name as the function? The intent is > > likely > > to have the return value assigned by CALERF_r8. So it also looks like > > gfortran miscompiles such testcase. [...] > SUBROUTINE Y (Z) > real(8), intent(out) :: Z > Z = 1. > END SUBROUTINE Y > FUNCTION X() > real(8) :: X > CALL Y (X) > END FUNCTION X > PROGRAM TEST > real(8) :: Z > Z = X(); > if (Z.ne.1.) STOP 1 > END PROGRAM > > but still > > t.f90:11:9: > > 11 | Z = X(); > | 1 > Error: Return type mismatch of function 'x' at (1) (REAL(4)/REAL(8)) The error message is correct. The main program is missing a decl that X is real(8) not real(4). E.g. adding real(8) :: X resolves the type mismatch. (Replacing 1. by 1._8 also eliminates some conversions in the dump.) The dummy argument Z of Y is marked as intent(out): Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = y symtree: 'y' || symbol: 'y' type spec : (UNKNOWN 0) attributes: (PROCEDURE SUBROUTINE) Formal arglist: z symtree: 'z' || symbol: 'z' type spec : (REAL 8) attributes: (VARIABLE DUMMY(OUT)) A quick glance at trans-expr.cc::gfc_conv_procedure_call suggests that the logic that determines whether to generate a clobber depends on the properties of the formal argument being available. 6505 bool add_clobber; 6506 add_clobber = fsym && fsym->attr.intent == INTENT_OUT 6507 && !fsym->attr.allocatable && !fsym->attr.pointer 6508 && e->symtree && e->symtree->n.sym 6509 && !e->symtree->n.sym->attr.dimension 6510 && !e->symtree->n.sym->attr.pointer 6511 && !e->symtree->n.sym->attr.allocatable 6512 /* See PR 41453. */ 6513 && !e->symtree->n.sym->attr.dummy 6514 /* FIXME - PR 87395 and PR 41453 */ 6515 && e->symtree->n.sym->attr.save == SAVE_NONE 6516 && !e->symtree->n.sym->attr.associate_var 6517 && e->ts.type != BT_CHARACTER && e->ts.type != BT_DERIVED 6518 && e->ts.type != BT_CLASS && !sym->attr.elemental; 6519 6520 gfc_conv_expr_reference (&parmse, e, add_clobber); (gdb) p fsym $7 = (gfc_symbol *) 0x0 Without an explicit interface, stone-age-style code is not supported here yet.
next prev parent reply other threads:[~2022-08-24 19:36 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 [this message] 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 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-2db7RHVDRZ@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).