[Bug fortran/60091] Misleading error messages in rank-2 pointer assignment to rank-1 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60091 --- Comment #3 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Fri Mar 15 22:20:20 2019 New Revision: 269717 URL: https://gcc.gnu.org/viewcvs?rev=269717&root=gcc&view=rev Log: 2019-03-15 Harald Anlauf PR fortran/60091 * expr.c (gfc_check_pointer_assign): Correct and improve error messages for invalid pointer assignments. PR fortran/60091 * gfortran.dg/pointer_remapping_3.f08: Adjust error messages. * gfortran.dg/pointer_remapping_7.f90: Adjust error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pointer_remapping_3.f08 trunk/gcc/testsuite/gfortran.dg/pointer_remapping_7.f90
[Bug fortran/60091] Misleading error messages in rank-2 pointer assignment to rank-1 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60091 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed on trunk.
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
The following patch generates errors for the testcases when one
of the TRANSFER arguments is a procedure (but not a pointer):
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 269717)
+++ gcc/fortran/check.c (working copy)
@@ -5551,6 +5551,24 @@
return false;
}
+ if (source->ts.type == BT_PROCEDURE
+ && !source->symtree->n.sym->attr.pointer)
+{
+ gfc_error ("% argument of % intrinsic at %L "
+ "must not be a %s", &source->where,
+gfc_basic_typename (source->ts.type));
+ return false;
+}
+
+ if (mold->ts.type == BT_PROCEDURE
+ && !mold->symtree->n.sym->attr.pointer)
+{
+ gfc_error ("% argument of % intrinsic at %L "
+ "must not be a %s", &mold->where,
+gfc_basic_typename (mold->ts.type));
+ return false;
+}
+
if (size != NULL)
{
if (!type_check (size, 2, BT_INTEGER))
Needs regtesting.
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #3) In class.c we have: Breakpoint 1, find_intrinsic_vtab (ts=0x2474758) at ../../trunk/gcc/fortran/class.c:2715 2715gfc_element_size (e, &e_size); (gdb) p e->ts.type $8 = BT_PROCEDURE This case is something that is generally not handled. What is the storage size of procedure (pointers)? This needs to be added in gfc_element_size or gfc_typenode_for_spec, and the call in class.c needs to be adjusted accordingly.
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
The following patch fixes the ICE:
Index: trans-types.c
===
--- trans-types.c (revision 269779)
+++ trans-types.c (working copy)
@@ -1194,6 +1194,9 @@
basetype = pfunc_type_node;
}
break;
+case BT_PROCEDURE:
+ basetype = pfunc_type_node;
+ break;
default:
gcc_unreachable ();
}
Index: target-memory.c
===
--- target-memory.c (revision 269779)
+++ target-memory.c (working copy)
@@ -120,6 +120,7 @@
case BT_CLASS:
case BT_VOID:
case BT_ASSUMED:
+case BT_PROCEDURE:
{
/* Determine type size without clobbering the typespec for ISO C
binding types. */
However, I do not have a working code sample to run.
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #13 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #12) > > Sorry, I am confused, I think Comment 1 already has such a reduced test. > > At least the what it says there ... > > It is a reduced test for the ICE (as are further reduced tests in comments 3 > and 9), > but they do not allow to check that fortran is not producing a wrong code > instead of an ICE. > > I understand > > > However, I do not have a working code sample to run. > > as asking for such a test. Exactly. Taking this PR. It has some overlap to PR85797 and can probably be fixed with the same patch.
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #15 from anlauf at gcc dot gnu.org --- (In reply to DIL from comment #14) > Ok, so you are still looking for a single Fortran source file using this > feature, namely optional dummy procedure pointers, that would do something > non-trivial with them and produce PASS/FAIL output? If yes, then I can try > making such a reduced test (if needed). I am just not familiar with GNU test > requirements. Exactly. Just assume that many thousands of tests are run for regression testing each time, and productivity of the developers depends on the turnaround time.
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Revised patch that also addresses PR83515: https://gcc.gnu.org/ml/fortran/2019-03/msg00109.html
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 18:33:51 2019 New Revision: 270045 URL: https://gcc.gnu.org/viewcvs?rev=270045&root=gcc&view=rev Log: 2019-03-31 Harald Anlauf PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #16 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 18:33:51 2019 New Revision: 270045 URL: https://gcc.gnu.org/viewcvs?rev=270045&root=gcc&view=rev Log: 2019-03-31 Harald Anlauf PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #17 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 19:08:23 2019 New Revision: 270046 URL: https://gcc.gnu.org/viewcvs?rev=270046&root=gcc&view=rev Log: 2019-03-31 Harald Anlauf PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/target-memory.c branches/gcc-8-branch/gcc/fortran/trans-types.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797 --- Comment #7 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 19:08:23 2019 New Revision: 270046 URL: https://gcc.gnu.org/viewcvs?rev=270046&root=gcc&view=rev Log: 2019-03-31 Harald Anlauf PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/target-memory.c branches/gcc-8-branch/gcc/fortran/trans-types.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #18 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 19:21:37 2019 New Revision: 270047 URL: https://gcc.gnu.org/viewcvs?rev=270047&root=gcc&view=rev Log: 2019-03-31 Harald Anlauf Backport from trunk PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/target-memory.c branches/gcc-7-branch/gcc/fortran/trans-types.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797 --- Comment #8 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 19:21:37 2019 New Revision: 270047 URL: https://gcc.gnu.org/viewcvs?rev=270047&root=gcc&view=rev Log: 2019-03-31 Harald Anlauf Backport from trunk PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/target-memory.c branches/gcc-7-branch/gcc/fortran/trans-types.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on trunk and open branches (7/8). Thanks for the report!
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from anlauf at gcc dot gnu.org --- Fixed on trunk and all open branches (7/8). Closing, as no reduced run-time testcase was provided. Please reopen or create a new PR if an issue is found. Thanks for the report!
[Bug fortran/88139] ICE in get_c_type_name, at fortran/dump-parse-tree.c:3047
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88139 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #5) > (In reply to kargl from comment #4) > > I had a patch for this, but lost it when committing my last 10 patches. > > Thankfully, there are mailing list archives. See > > https://gcc.gnu.org/ml/fortran/2018-12/msg00038.html > > for the patch. Steve, do you plan to submit it before it bit-rots?
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #21 from anlauf at gcc dot gnu.org --- (In reply to DIL from comment #20) > Thanks for fixing this bug! Sorry, I have not had time yet to create a > reduced non-trivial test case. Would you still like to add it later if I > make it? If yes, should I just attach it later to this closed bug report? Just attach it to this PR. I'll try to take care of it.
[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85868 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52351 --- Comment #7 from anlauf at gcc dot gnu.org --- PR52351 (Wrong bounds when passing an array section to an intent-in pointer dummy) is related to this one.
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #1 from anlauf at gcc dot gnu.org --- Can you find out which of the tests in file pr85797.f90 triggers the ICE?
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to seurer from comment #3) > Best I can tell from poking around in gdb is that it is happening at line 32 > > end subroutine s > > that's probably not much help. Sorry! So if you comment out lines 24-33 (the part "module m" until the final "end"), there's no ICE, and if you keep only those lines (commenting lines 6-22), there's no ICE? This would mean that PR83515 either is not completely fixed, or the fix exposes something else that doesn't show up on x86_64. I see the following options: - XFAIL the testcase where needed, until this PR gets fixed (maybe there's a related issue) - reopen PR83515 and remove lines 24-33 from the testcase; the tests given that PR may succeed on x86_64, but lead to an ICE in a different place elsewhere
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #4) > and if you keep only those lines (commenting lines 6-22), > there's no ICE? Sorry, I meant there an ICE here on your target.
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to seurer from comment #6) > Actually, it is the opposite. Oh, that is surprising. So if you comment out subroutine f, there's no ICE? And if you keep only subroutine a and subroutine f, it ICEs?
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to seurer from comment #8) > With no f: ICE > > With only subroutine a and subroutine f: no ICE Now it gets really mysterious. If you start from the full testcase, and remove - starting from the end - block for block: first module m, then subroutine f, then subroutine e, then subroutine d, what does trigger the ICE?
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #16 from anlauf at gcc dot gnu.org --- I had rejected procedure arguments to TRANSFER in my initial patch, see https://gcc.gnu.org/ml/fortran/2019-03/msg00099.html but Thomas persuaded me to be less strict. So shall I resubmit my original patch, or is Steve's comment#11 better? Of course the testcase needs adjustments.
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #19 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #17) > > So shall I resubmit my original patch, or is Steve's comment#11 better? > > I'ld take Steve's conditions, but your wording for the errors!-) Steve's patch would not reject: subroutine f use, intrinsic :: iso_c_binding integer(c_intptr_t) :: b, c procedure(), pointer :: a c = transfer (a, b) c = transfer (transfer (b, a), b) end so this is probably what Thomas had in mind. I'll package the patch and submit.
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #20 from anlauf at gcc dot gnu.org --- Patch here: https://gcc.gnu.org/ml/fortran/2019-04/msg3.html
[Bug d/89004] mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89004 --- Comment #2 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Thu Apr 4 20:38:33 2019 New Revision: 270150 URL: https://gcc.gnu.org/viewcvs?rev=270150&root=gcc&view=rev Log: 2019-04-04 Harald Anlauf PR fortran/89004 * check.c (gfc_check_transfer): Reject procedures as actual arguments for SOURCE and MOLD of TRANSFER intrinsic. PR fortran/89004 * gfortran.dg/pr85797.f90: Adjust testcase. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr85797.f90
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #21 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #20) > Patch here: > > https://gcc.gnu.org/ml/fortran/2019-04/msg3.html Patch applied to trunk so far. Unfortunately, I had the wrong PR in the ChangeLog (PR89004). :-( Sorry for that. I should get that right for the backports. Will wait for a couple of days to see if there is further fallout.
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #22 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Apr 7 19:42:05 2019 New Revision: 270192 URL: https://gcc.gnu.org/viewcvs?rev=270192&root=gcc&view=rev Log: 2019-04-07 Harald Anlauf PR fortran/89904 * ChangeLog: Correct ChangeLog entry. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #24 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Wed Apr 10 20:26:44 2019 New Revision: 270265 URL: https://gcc.gnu.org/viewcvs?rev=270265&root=gcc&view=rev Log: 2019-04-10 Harald Anlauf Backport from trunk PR fortran/89904 * check.c (gfc_check_transfer): Reject procedures as actual arguments for SOURCE and MOLD of TRANSFER intrinsic. PR fortran/89904 * gfortran.dg/pr85797.f90: Adjust testcase. Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/check.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr85797.f90
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #25 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Wed Apr 10 21:02:02 2019 New Revision: 270268 URL: https://gcc.gnu.org/viewcvs?rev=270268&root=gcc&view=rev Log: 2019-04-10 Harald Anlauf Backport from trunk PR fortran/89904 * check.c (gfc_check_transfer): Reject procedures as actual arguments for SOURCE and MOLD of TRANSFER intrinsic. PR fortran/89904 * gfortran.dg/pr85797.f90: Adjust testcase. Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/check.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85797.f90
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from anlauf at gcc dot gnu.org --- Should be fixed on trunk, 8-branch and 7-branch. Closing.
[Bug fortran/90578] Wrong code with LSHIFT and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #3) > On Thu, 23 May 2019, dominiq at lps dot ens.fr wrote: > > I don't see any mention of "left-shift by negative value is undefined". > > But it doesn't define what happens either ;) Thus it is "undefined" :P > > So, if the GNU extension would document it as "A LSHIFT by a > negative value is treated as a RSHIFT" then the frontend has > to emit y < 0 ? x >> y : x << y since what I am saying is that > the middle-end follows the C standard here and treats negative > shift amounts as undefined. The gfortran documentation of LSHIFT (and RSHIFT) mentions: "This function has been superseded by the ISHFT intrinsic, which is standard in Fortran 95 and later." The natural solution would be to implement LSHIFT/RSHIFT in terms of ISHFT, which does handle positive and negative shifts. I might have a look at it.
[Bug fortran/90578] Wrong code with LSHIFT and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) > Compiling > > print *, lshift(1,-1) > end > > gives the following error > > lshift.f90:1:16: > > 1 | print *, lshift(1,-1) > |1 > Error: Second argument of LSHIFT is negative at (1) > > While > > print *, ishft(2,-1) > end > > gives > >1 Can you please explain what you expect? Keep the current implementation, where negative shifts are disallowed for lshift/rshift? Then fix the documentation, explaining that negative shifts have undefined behavior. Related testcases in the testsuite need to be fixed. Or allow negative shifts, as in ishft?
[Bug fortran/90578] Wrong code with LSHIFT and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578 --- Comment #8 from anlauf at gcc dot gnu.org --- Patch at https://gcc.gnu.org/ml/fortran/2019-06/msg00077.html
[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577 --- Comment #5 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Fri Jun 14 18:41:20 2019 New Revision: 272309 URL: https://gcc.gnu.org/viewcvs?rev=272309&root=gcc&view=rev Log: 2019-06-14 Harald Anlauf PR fortran/90577 PR fortran/90578 * trans-intrinsic.c (gfc_conv_intrinsic_shift): Properly distinguish logical/arithmetic shifts. * intrinsic.texi: Update documentation for SHIFTR/SHIFTL/SHIFTA (Fortran 2008) and LSHIFT/RSHIFT (GNU extensions). PR fortran/90577 PR fortran/90578 * gfortran.dg/lrshift_1.f90: Adjust testcase. * gfortran.dg/shiftalr_3.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/shiftalr_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/lrshift_1.f90
[Bug fortran/90578] Wrong code with LSHIFT and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578 --- Comment #9 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Fri Jun 14 18:41:20 2019 New Revision: 272309 URL: https://gcc.gnu.org/viewcvs?rev=272309&root=gcc&view=rev Log: 2019-06-14 Harald Anlauf PR fortran/90577 PR fortran/90578 * trans-intrinsic.c (gfc_conv_intrinsic_shift): Properly distinguish logical/arithmetic shifts. * intrinsic.texi: Update documentation for SHIFTR/SHIFTL/SHIFTA (Fortran 2008) and LSHIFT/RSHIFT (GNU extensions). PR fortran/90577 PR fortran/90578 * gfortran.dg/lrshift_1.f90: Adjust testcase. * gfortran.dg/shiftalr_3.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/shiftalr_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/lrshift_1.f90
[Bug fortran/90578] Wrong code with LSHIFT and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from anlauf at gcc dot gnu.org --- Testcase fixed to no longer invoke undefined behavior. Documentation fixed, as well as arithmetic shifts which SHIFT=BIT_SIZE(arg1). No runtime test for invalid SHIFT values. Please open a separate PR if you think this is important.
[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||anlauf at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on trunk for the invalid testcase. Can someone please check/confirm that it solves the LTO issues? Leaving open for possible backport to 9-branch, unless some fallout shows up.
[Bug fortran/90903] New: Implement runtime checks for bit manipulation intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90903 Bug ID: 90903 Summary: Implement runtime checks for bit manipulation intrinsics Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- The Fortran standard imposes constraints on some arguments (e.g. SHIFT) on the bit manipulation intrinsics (e.g. SHIFTR/SHIFTL/SHIFTA, ISHFT, IBSET/IBCLR). There are compile-time checks, but so far no runtime checks. It would be useful to have runtime check to catch undefined behavior. This requires a new option, e.g. -fcheck=bits (analogous to what NAG provides).
[Bug fortran/90903] Implement runtime checks for bit manipulation intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90903 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P5 Severity|normal |enhancement
[Bug fortran/90578] Wrong code with LSHIFT and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578 --- Comment #11 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Tue Jun 18 20:21:47 2019 New Revision: 272437 URL: https://gcc.gnu.org/viewcvs?rev=272437&root=gcc&view=rev Log: 2019-06-18 Harald Anlauf Backport from mainline 2019-06-14 Harald Anlauf PR fortran/90577 PR fortran/90578 * trans-intrinsic.c (gfc_conv_intrinsic_shift): Properly distinguish logical/arithmetic shifts. * intrinsic.texi: Update documentation for SHIFTR/SHIFTL/SHIFTA (Fortran 2008) and LSHIFT/RSHIFT (GNU extensions). PR fortran/90577 PR fortran/90578 * gfortran.dg/lrshift_1.f90: Adjust testcase. * gfortran.dg/shiftalr_3.f90: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/shiftalr_3.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/intrinsic.texi branches/gcc-9-branch/gcc/fortran/trans-intrinsic.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/lrshift_1.f90
[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577 --- Comment #8 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Tue Jun 18 20:21:47 2019 New Revision: 272437 URL: https://gcc.gnu.org/viewcvs?rev=272437&root=gcc&view=rev Log: 2019-06-18 Harald Anlauf Backport from mainline 2019-06-14 Harald Anlauf PR fortran/90577 PR fortran/90578 * trans-intrinsic.c (gfc_conv_intrinsic_shift): Properly distinguish logical/arithmetic shifts. * intrinsic.texi: Update documentation for SHIFTR/SHIFTL/SHIFTA (Fortran 2008) and LSHIFT/RSHIFT (GNU extensions). PR fortran/90577 PR fortran/90578 * gfortran.dg/lrshift_1.f90: Adjust testcase. * gfortran.dg/shiftalr_3.f90: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/shiftalr_3.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/intrinsic.texi branches/gcc-9-branch/gcc/fortran/trans-intrinsic.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/lrshift_1.f90
[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Should be fixed on 10-trunk and 9-branch. Runtime checks for the bit manipulation intrinsics will be tracked in PR90903.
[Bug fortran/90903] Implement runtime checks for bit manipulation intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90903 --- Comment #1 from anlauf at gcc dot gnu.org --- Patch addressing the bit manipulation functions so far: https://gcc.gnu.org/ml/fortran/2019-06/msg00138.html
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #28 from anlauf at gcc dot gnu.org --- Patch for accepts-invalid / ice-on-invalid-code (parameter + data) part: https://gcc.gnu.org/pipermail/fortran/2021-March/055768.html
[Bug fortran/99368] ICE in build_function_decl, at fortran/trans-decl.c:2381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99368 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Last reconfirmed||2021-03-03 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. The error message for case z2 is misleading, too. We should report either a type conflict or better reject simply because the declaration comes after the namelist statement. I thought we had fixed this (see pr98686).
[Bug libfortran/99218] [8/9/10/11 Regression] matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/99345] [11 Regression] ICE in doloop_contained_procedure_code, at fortran/frontend-passes.c:2464 since r11-2578-g27eac9ee6137a6b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99345 --- Comment #10 from anlauf at gcc dot gnu.org --- Further reduced: DO iq = 1, nq CALL calc_upper_fan (iq) ENDDO CONTAINS SUBROUTINE calc_upper_fan (iq) INTEGER :: iq INTEGER :: recl INQUIRE(IOLENGTH=recl) iq END END
[Bug fortran/99205] [10/11 Regression] Out of memory with undefined character length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-03-08 Status|UNCONFIRMED |NEW Known to work||9.3.1 Known to fail||10.2.1, 11.0 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. gcc-9 gave: pr99205.f90:2:12: 2 | character(l) :: c(2) |1 Error: Variable 'l' cannot appear in the expression at (1) pr99205.f90:2:22: 2 | character(l) :: c(2) | 1 Error: 'c' at (1) must have constant character length in this context pr99205.f90:3:16: 3 | data c /'a', 'b'/ |1 Warning: Initialization string at (1) was truncated to fit the variable (0/1)
[Bug fortran/99205] [10/11 Regression] Out of memory with undefined character length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205 --- Comment #2 from anlauf at gcc dot gnu.org --- This fixes the testcase and passes regtesting: diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c index 25e97930169..71e2552025d 100644 --- a/gcc/fortran/data.c +++ b/gcc/fortran/data.c @@ -595,6 +595,9 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index, /* An initializer has to be constant. */ if (lvalue->ts.u.cl->length == NULL && !(ref && ref->u.ss.length != NULL)) return false; + if (lvalue->ts.u.cl->length + && lvalue->ts.u.cl->length->expr_type != EXPR_CONSTANT) + return false; expr = create_character_initializer (init, last_ts, ref, rvalue); if (!expr) return false;
[Bug fortran/99205] [10/11 Regression] Out of memory with undefined character length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-March/055782.html
[Bug fortran/99506] internal compiler error: in record_reference, at cgraphbuild.c:64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99506 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) > I don't know fortran enough for what 'parameter' means in this context: > >real(double), parameter:: latt(jmax) = [(latt100(i)/100.d0, j=1,jmax)] > > but the middle-end sees a readonly global (TREE_STATIC) variable. There is a possibly related issue in pr91960.
[Bug fortran/99112] [11 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99112
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #2)
> For whatever reason, the chunk in gfc_conv_intrinsic_size doesn't quite work
> correctly because the wrong message is selected. Thus a bit more work is
> required
Playing around with reduced testcases shows that the origin might be
rather obscure. The following case does not generate any runtime error
with -fcheck=pointer:
module m
type t
end type
contains
function f(x) result(z)
integer :: x(:)
type(t) :: z(size(x))
end
subroutine s
integer :: a(2)
class(t), allocatable :: c(:)
c = f(a)
end
end
while replacing the type of dummy x in f to class(*):
module m
type t
end type
contains
function f(x) result(z)
class(*) :: x(:)
type(t) :: z(size(x))
end
subroutine s
integer :: a(2)
class(t), allocatable :: c(:)
c = f(a)
end
end
now has in the dump tree within the caller s:
_gfortran_runtime_error_at (&"At line 7 of file pr99112-z3.f90"[1]{lb: 1 sz:
1}, &"Pointer argument \'x\' is not associated"[1]{lb: 1 sz: 1});
[Bug fortran/99112] [11 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99112
--- Comment #4 from anlauf at gcc dot gnu.org ---
A simple one-liner on top of Paul's patch fixes it:
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 9cf3642f694..5e53d1162fa 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -8006,8 +8006,10 @@ gfc_conv_intrinsic_size (gfc_se * se, gfc_expr * expr)
{
symbol_attribute attr;
char *msg;
+ tree temp;
+ tree cond;
- attr = gfc_expr_attr (e);
+ attr = sym ? sym->attr : gfc_expr_attr (e);
if (attr.allocatable)
msg = xasprintf ("Allocatable argument '%s' is not allocated",
e->symtree->n.sym->name);
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-March/055809.html
[Bug fortran/99585] New: ICE with SIZE intrinsic on nested derived type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99585 Bug ID: 99585 Summary: ICE with SIZE intrinsic on nested derived type components Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- As reported by Tobias Burnus in https://gcc.gnu.org/pipermail/fortran/2021-March/055815.html the following code ICEs with all gcc since at least 7: module m type t class(*), pointer :: bar(:) end type type t2 class(t), allocatable :: my(:) end type t2 contains function f (x, y) result(z) class(t) :: x(:) class(t) :: y(size(x(1)%bar)) type(t) :: z(size(x(1)%bar)) end function g (x) result(z) class(t) :: x(:) type(t) :: z(size(x(1)%bar)) end subroutine s () class(t2), allocatable :: a(:), b(:), c(:), d(:) class(t2), pointer :: p(:) c(1)%my = f (a(1)%my, b(1)%my) d(1)%my = g (p(1)%my) end end
[Bug fortran/99585] ICE with SIZE intrinsic on nested derived type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99585 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Keywords||ice-on-valid-code Last reconfirmed||2021-03-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to fail||10.2.1, 11.0, 7.5.0, 8.4.1, ||9.3.1
[Bug fortran/99112] [11 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99112 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from anlauf at gcc dot gnu.org --- Committed to mainline for gcc-11. This fixes the testcase, but there are related cases which are not addressed yet, see e.g. pr99585 which ICEs even without -fcheck=pointer. Thanks for the report!
[Bug fortran/99585] ICE with SIZE intrinsic on nested derived type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99585 --- Comment #1 from anlauf at gcc dot gnu.org --- Reduced example: module m type t end type type t2 type(t), allocatable :: my(:) end type t2 contains function h (x) result(z) class(t2) :: x(:) type(t) :: z(size(x(1)%my)) end subroutine s () type(t2), allocatable :: a(:) type(t), allocatable :: u(:) u = h (a) end end
[Bug fortran/99585] ICE with SIZE intrinsic on nested derived type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99585 --- Comment #2 from anlauf at gcc dot gnu.org --- Actually the SIZE intrinsic might be a red herring, as the following variant does also ICE: module m type t end type type t2 integer :: n end type t2 contains function h (x) result(z) class(t2) :: x(:) ! ICE ! type(t2) :: x(:) ! no ICE type(t) :: z(x(1)%n) end subroutine s type(t2), allocatable :: a(:) type(t), allocatable :: u(:) u = h (a) end end
[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #6 from anlauf at gcc dot gnu.org ---
The following patch fixes several NULL pointer dereferences exhibited by the
testcases in comment#0 and comment#5:
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index a6df885c80c..153e9037127 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -3714,7 +3714,7 @@ gfc_match_rvalue (gfc_expr **result)
e->where = gfc_current_locus;
if (sym->ts.type == BT_CLASS && sym->attr.class_ok
- && CLASS_DATA (sym)->as)
+ && CLASS_DATA (sym) && CLASS_DATA (sym)->as)
e->rank = CLASS_DATA (sym)->as->rank;
else if (sym->as != NULL)
e->rank = sym->as->rank;
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 32015c21efc..59870bbd502 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8902,6 +8902,8 @@ resolve_select (gfc_code *code, bool select_type)
bool
gfc_type_is_extensible (gfc_symbol *sym)
{
+ if (sym == NULL)
+return false;
return !(sym->attr.is_bind_c || sym->attr.sequence
|| (sym->attr.is_class
&& sym->components->ts.u.derived->attr.unlimited_polymorphic));
@@ -12747,6 +12749,7 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
&& sym->ts.u.derived
&& !sym->attr.select_type_temporary
&& !UNLIMITED_POLY (sym)
+ && CLASS_DATA (sym)
&& !gfc_type_is_extensible (CLASS_DATA (sym)->ts.u.derived))
{
gfc_error ("Type %qs of CLASS variable %qs at %L is not extensible",
@@ -15432,7 +15435,8 @@ resolve_symbol (gfc_symbol *sym)
specification_expr = saved_specification_expr;
}
- if (sym->ts.type == BT_CLASS && sym->attr.class_ok && sym->ts.u.derived)
+ if (sym->ts.type == BT_CLASS && sym->attr.class_ok && sym->ts.u.derived
+ && CLASS_DATA (sym))
{
as = CLASS_DATA (sym)->as;
class_attr = CLASS_DATA (sym)->attr;
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602 --- Comment #14 from anlauf at gcc dot gnu.org --- (In reply to Jürgen Reuter from comment #13) > Cool, thanks for the quick reaction, Paul. Maybe Harald can have a look at > it as well :D LGTM. It's by Paul. He simply needs to get the testcase's dg-foo right... ;-)
[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138 --- Comment #7 from anlauf at gcc dot gnu.org --- The patch in comment#6 generates an unexpected error: pr99138.f90:11:2: 11 | module function f(x) | 1 Error: Type mismatch in function result (CLASS(STAR)/CLASS(*)) between the MODULE PROCEDURE declaration in MODULE 'm' and the declaration at (1) in (SUB)MODULE 'm2' Replacing the module function part with module procedure f end makes the code compile, so I think this is an independent issue... :-(
[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138
--- Comment #8 from anlauf at gcc dot gnu.org ---
The check in interface.c:gfc_check_result_characteristics has an asymmetry
coming from symbol.c:gfc_type_compatible that could be evaded by swapping
arguments:
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index f7ca52e6550..8758f146d57 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -1561,7 +1561,7 @@ gfc_check_result_characteristics (gfc_symbol *s1,
gfc_symbol *s2,
return true;
/* Check type and rank. */
- if (!compare_type_characteristics (r1, r2))
+ if (!compare_type_characteristics (r2, r1))
{
snprintf (errmsg, err_len, "Type mismatch in function result (%s/%s)",
gfc_typename (&r1->ts), gfc_typename (&r2->ts));
However, we then hits other issues later on with the ALLOCATABLE attribute.
:-(
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #15)
> > LGTM. It's by Paul. He simply needs to get the testcase's dg-foo right...
> > ;-)
>
> Now I'm confused. So you consider the fix ok? Will it then be committed?
The fix was basically OKed on the fortran ML by Tobias, he only wondered
if there should be a runtime test. One could simply change the line
! { dg-do compile }
to
! { dg-do run }
before committing. Still confused?
[Bug fortran/99609] Pure Function that has a Variable with Value Attribute that is modified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99609 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- The patch for pr97491 appears simple and safe. I could check if a "backport" works unless there are objections.
[Bug fortran/99205] [10/11 Regression] Out of memory with undefined character length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11, and on 10-branch. Thanks for the report!
[Bug fortran/99688] AddressSanitizer: stack-buffer-overflow on address at gfc_match_name(char*) gcc/fortran/match.c:685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99688
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
I do not see the issue with valgrind, but does the following obvious patch
help?
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 4d5890fd523..9941887453f 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -6634,7 +6634,7 @@ gfc_match_select_rank (void)
{
gfc_expr *expr1, *expr2 = NULL;
match m;
- char name[GFC_MAX_SYMBOL_LEN];
+ char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_symbol *sym, *sym2;
gfc_namespace *ns = gfc_current_ns;
gfc_array_spec *as = NULL;
There might be a similar issue with SELECT TYPE (gfc_match_select_type).
[Bug fortran/99709] [PDT] VALUE attribute for an object with nonconstant length parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99709 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|VALUE attribute for an |[PDT] VALUE attribute for |object with nonconstant |an object with nonconstant |length parameter|length parameter Ever confirmed|0 |1 Priority|P3 |P4 Last reconfirmed||2021-03-22 Keywords||wrong-code --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Seems to require PDTs. Funnily Intel has exactly the same issue. NAG gets it right.
[Bug fortran/99369] [10/11 Regression] ICE in gfc_resolve_expr, at fortran/resolve.c:7167
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99369 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Another data point: placing the code into one module makes the code compile: module mabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab type tabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab end type interface operator(.oabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab.) module procedure fabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab end interface contains function fabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab & (uabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab, & vabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab) type(tabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab), intent(in) :: & uabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab, & vabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab end subroutine p () type(tabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab) :: & uabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab, & vabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab wabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab = & uabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab & .oabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab. & vabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzabcdefgxyzab end end
[Bug libfortran/99740] floating point exception in rand() in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99740 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-03-23 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from anlauf at gcc dot gnu.org --- rand(3f) is not a Fortran standard function but provided by your Linux system. The man page says: rand and drand return values in the range 0.0 through 1.0. So rand may return 0. and an FP exception is not surprising. If you agree we close your report as invalid.
[Bug fortran/96859] Wrong answer with intrinsic merge_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #13 from anlauf at gcc dot gnu.org --- Anything left to do or can the PR be closed?
[Bug fortran/96012] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96012 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from anlauf at gcc dot gnu.org --- This PR appears to remain an 8-only regression, as the testcases in comment#0 do compile now. Shall this PR be closed?
[Bug fortran/99348] ICE in resolve_structure_cons, at fortran/resolve.c:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99348
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
There's no ICE when x is scalar:
type(t), parameter :: x = t('abc')
With the following patch we avoid the NULL pointer dereference at
resolve.c:1286
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 1c9b0c5cb62..0b9e11cdd41 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1282,7 +1282,7 @@ resolve_structure_cons (gfc_expr *expr, int init)
/* A constructor may have references if it is the result of substituting a
parameter variable. In this case we just pull out the component we
want. */
- if (expr->ref)
+ if (expr->ref && expr->ref->u.c.sym)
comp = expr->ref->u.c.sym->components;
else
comp = expr->ts.u.derived->components;
but later run into an issue at expr.c:1917:
1913 for (c = gfc_constructor_first
(p->value.constructor);
1914 c; c = gfc_constructor_next (c))
1915{
1916 c->expr->ref = gfc_copy_ref (p->ref->next);
1917 if (!simplify_const_ref (c->expr))
1918return false;
1919}
(gdb) p c->expr->ts.u.cl->length
$104 = (gfc_expr *) 0x0
(gdb) p c->expr->value.character.length
$105 = 3
This leads to an ICE during processing simplify_const_ref.
[Bug fortran/99798] ICE when compiling a variant of pr87907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed||2021-03-27 Status|UNCONFIRMED |NEW
[Bug fortran/99817] [10/11 Regression] ICE in create_function_arglist, at fortran/trans-decl.c:2838 (etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99817 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org, ||burnus at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- The ICE happens in Program received signal SIGSEGV, Segmentation fault. create_function_arglist (sym=) at ../../gcc-trunk/gcc/fortran/trans-decl.c:2838 2838 hidden_typelist = TREE_CHAIN (hidden_typelist); (gdb) git blame points to: commit 212f4988f37ccf788c8c72b1dc952980bc9be3b7 Author: Tobias Burnus Date: Tue Mar 23 15:45:36 2021 +0100 Fortran: Fix func decl mismatch [PR93660] Adding Tobias.
[Bug fortran/99819] [9/10/11 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-30 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. I believe there are tons of duplicates of this one.
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-03-30 Known to fail||10.2.1, 11.0, 8.4.1, 9.3.1 Priority|P3 |P4 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. This one is funny. The TRANSPOSE seems to screw up the simplification. Works without TRANSPOSE.
[Bug fortran/99839] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||anlauf at gcc dot gnu.org,
||tkoenig at gcc dot gnu.org
Last reconfirmed||2021-03-30
Ever confirmed|0 |1
Priority|P3 |P4
--- Comment #1 from anlauf at gcc dot gnu.org ---
This one is funny. Simply punting on non-numeric and non-logical results
works around the ICE.
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index 7d3eae67632..213530e46e1 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -4193,6 +4193,19 @@ inline_matmul_assign (gfc_code **c, int *walk_subtrees,
if (m_case == none)
return 0;
+ /* We only handle assignment to numeric or logical variables. */
+ switch(expr1->ts.type)
+{
+case BT_INTEGER:
+case BT_LOGICAL:
+case BT_REAL:
+case BT_COMPLEX:
+ break;
+
+default:
+ return 0;
+}
+
ns = insert_block ();
/* Assign the type of the zero expression for initializing the resulting
Adding Thomas, who knows the code better.
[Bug fortran/99839] [8/9/10/11 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |8.5 Summary|ICE in |[8/9/10/11 Regression] ICE |inline_matmul_assign, at|in inline_matmul_assign, at |fortran/frontend-passes.c:4 |fortran/frontend-passes.c:4 |234 |234
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840
--- Comment #4 from anlauf at gcc dot gnu.org ---
For reasons I do not understand,
Breakpoint 1, gfc_simplify_matmul (matrix_a=0x292bbf0, matrix_b=0x292c550)
at ../../gcc-trunk/gcc/fortran/simplify.c:4777
4777 result_columns = mpz_get_si (matrix_b->shape[1]);
(gdb) p matrix_b->shape[1]
$64 = {{_mp_alloc = 0, _mp_size = 0, _mp_d = 0x0}}
(gdb) p matrix_b->shape[0]
$65 = {{_mp_alloc = 0, _mp_size = 0, _mp_d = 0x0}}
This is a result from the mpz_set in gfc_simplify_transpose.
Isn't this a representation of zero?
Alternative patch, which passes the relevant regtesting:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 388aca7c38c..b884a81fce0 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -8123,16 +8123,16 @@ gfc_simplify_transpose (gfc_expr *matrix)
&matrix->where);
result->rank = 2;
result->shape = gfc_get_shape (result->rank);
- mpz_set (result->shape[0], matrix->shape[1]);
- mpz_set (result->shape[1], matrix->shape[0]);
+ matrix_rows = mpz_get_si (matrix->shape[0]);
+ matrix_cols = mpz_get_si (matrix->shape[1]);
+ mpz_init_set_si (result->shape[0], matrix_cols);
+ mpz_init_set_si (result->shape[1], matrix_rows);
if (matrix->ts.type == BT_CHARACTER)
result->ts.u.cl = matrix->ts.u.cl;
else if (matrix->ts.type == BT_DERIVED)
result->ts.u.derived = matrix->ts.u.derived;
- matrix_rows = mpz_get_si (matrix->shape[0]);
- matrix_cols = mpz_get_si (matrix->shape[1]);
for (row = 0; row < matrix_rows; ++row)
for (col = 0; col < matrix_cols; ++col)
{
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 --- Comment #5 from anlauf at gcc dot gnu.org --- OK, now I see it. gfc_get_shape does not init the resulting shape. The following simpler patch does the job: diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c index 388aca7c38c..c27b47aa98f 100644 --- a/gcc/fortran/simplify.c +++ b/gcc/fortran/simplify.c @@ -8123,8 +8123,8 @@ gfc_simplify_transpose (gfc_expr *matrix) &matrix->where); result->rank = 2; result->shape = gfc_get_shape (result->rank); - mpz_set (result->shape[0], matrix->shape[1]); - mpz_set (result->shape[1], matrix->shape[0]); + mpz_init_set (result->shape[0], matrix->shape[1]); + mpz_init_set (result->shape[1], matrix->shape[0]); if (matrix->ts.type == BT_CHARACTER) result->ts.u.cl = matrix->ts.u.cl;
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 --- Comment #8 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-March/055897.html
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on mainline and all open branches. Closing. Thanks for the report!
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #2) > The bug likely does not effect anyone that contributes code > to GCC. It does not affect me, but that is due my coding style (using public/private). > Fortunately, > there is a trivial work around, e.g., change the generic-name > from 'sqrt' to 'root'. Please don't do that. I already have my own generic root()... However, why in the world does an intrinsic need to show up in the module file in the first place? Consider: module mod1 implicit none real, parameter :: z = sqrt (0.0) end module mod1 Is there a reason why the intrinsic should not be prevented from occurring in the module file?
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
--- Comment #4 from anlauf at gcc dot gnu.org ---
The following patch regtests ok and fixes the testcase:
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 4db0a3ac76d..b4b7b437f86 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -6218,6 +6218,9 @@ write_symtree (gfc_symtree *st)
if (check_unique_name (st->name))
return;
+ if (strcmp (sym->module, "(intrinsic)") == 0)
+return;
+
p = find_pointer (sym);
if (p == NULL)
gfc_internal_error ("write_symtree(): Symbol not written");
It even fixes the slightly reduced & refined testcase:
module mod1
implicit none
real, parameter :: z = sqrt (0.0)
end module mod1
module mod2
implicit none
type t
real :: a = 0.
end type
interface sqrt
module procedure sqrt
end interface
contains
function sqrt (a)
type(t), intent(in) :: a
type(t) :: sqrt
sqrt% a = a% a
end function sqrt
end module mod2
program test
use mod1
use mod2
implicit none
type(t) :: x, y
y = sqrt (x)
end program test
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
--- Comment #6 from anlauf at gcc dot gnu.org ---
Steve, can you give an example for the procedure pointer case you mentioned?
I played a bit, but the only valid code that I can think of did not produce
a reference to sqrt in such a way that it needs to show up in the mod.
Extended testcase that compiles and also uses a procedure pointer to sqrt():
! { dg-do compile }
! PR63797 - Bogus ambiguous reference to 'sqrt'
module mod1
implicit none
real, parameter :: z = sqrt (0.0)
real:: w = sqrt (1.0)
interface
pure real function sqrt_ifc (x)
real, intent(in) :: x
end function sqrt_ifc
end interface
contains
pure function myroot () result (f)
procedure(sqrt_ifc), pointer :: f
intrinsic :: sqrt
f => sqrt
end function myroot
end module mod1
module mod2
implicit none
type t
real :: a = 0.
end type
interface sqrt
module procedure sqrt
end interface
contains
function sqrt (a)
type(t), intent(in) :: a
type(t) :: sqrt
sqrt% a = a% a
end function sqrt
end module mod2
program test
use mod1
use mod2
implicit none
type(t) :: x, y
procedure(sqrt_ifc), pointer :: root
root => myroot ()
y= sqrt (x)
y% a = sqrt (x% a) + z - w + root (x% a)
end program test
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #7) > which looks like a default initialization. Does sqrt need to be > recorded into the module? If not, then your patch is probably ok. My patch actually does not have any affect on the module file generated for your testcase. I'll add it to my testcase and submit.
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 --- Comment #9 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-April/055935.html
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-11, and backported to 10-branch as suggested by Paul. Closing. Thanks for the report!
[Bug fortran/99255] ICE in gfc_dt_upper_string, at fortran/module.c:441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255 --- Comment #2 from anlauf at gcc dot gnu.org --- Replacing class(t) :: x by class(t), allocatable :: x avoids the ICE. Could be an error recovery issue.
[Bug fortran/100136] [11 Regression] ICE, regression, using flag -fcheck=pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136 --- Comment #2 from anlauf at gcc dot gnu.org --- We do not properly handle the VALUE attribute. Reduced testcase: program p implicit none class(*), allocatable :: d call add_class (d) contains subroutine add_class (d) class(*), value :: d end subroutine end program
[Bug fortran/100154] [9/10/11 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org Last reconfirmed||2021-04-20 Target Milestone|--- |9.4 Status|UNCONFIRMED |NEW Priority|P3 |P4 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Workaround: add -std=f2018
[Bug fortran/100154] [9/10/11 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154
--- Comment #2 from anlauf at gcc dot gnu.org ---
Untested patch:
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 82db8e4e1b2..df4409840d5 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -5730,6 +5731,15 @@ gfc_check_fgetput_sub (gfc_expr *c, gfc_expr *status)
if (!kind_value_check (c, 0, gfc_default_character_kind))
return false;
+ if (c->expr_type != EXPR_VARIABLE
+ && strcmp (gfc_current_intrinsic, "fget") == 0)
+{
+ gfc_error ("%qs argument of %qs intrinsic at %L must be a variable",
+gfc_current_intrinsic_arg[0]->name,
+gfc_current_intrinsic, &c->where);
+ return false;
+}
+
if (status == NULL)
return true;
[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154 --- Comment #5 from anlauf at gcc dot gnu.org --- Created attachment 50651 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50651&action=edit WIP patch This patch reuses variable_check() and as a bonus fixes the declarations of the subroutine versions. It also checks the length of the character argument if known at compile time - it must not be 0. It does not accept the testcase in comment#4. This is possibly something that could be handled in variable_check().
[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #50651|0 |1 is obsolete|| --- Comment #6 from anlauf at gcc dot gnu.org --- Created attachment 50652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50652&action=edit WIP patch (corrected) Oops, I attached the pre-WIP version... Fixed now.
[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #4)
> as ptr_returning_func() (a function reference with data pointer result) is a
> variable in the sense of the Fortran standard (F2018:R902)?
Do you think the following is the right thing?
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 82db8e4e1b2..2c34c2b6786 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1055,6 +1055,12 @@ variable_check (gfc_expr *e, int n, bool allow_proc)
return true;
}
+ /* F2018:R902: function pointer having a data pointer result. */
+ if (e->expr_type == EXPR_FUNCTION
+ && e->symtree->n.sym->attr.flavor == FL_PROCEDURE
+ && e->symtree->n.sym->attr.pointer)
+return true;
+
gfc_error ("%qs argument of %qs intrinsic at %L must be a variable",
gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
&e->where);
That is sort of independent of the other parts of the patch, but would be
needed for a full fix.
[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> Do you think the following is the right thing?
Correction:
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 82db8e4e1b2..e1ec1c610e8 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1055,6 +1055,13 @@ variable_check (gfc_expr *e, int n, bool allow_proc)
return true;
}
+ /* F2018:R902: function reference having a data pointer result. */
+ if (e->expr_type == EXPR_FUNCTION
+ && e->symtree->n.sym->attr.flavor == FL_PROCEDURE
+ && e->symtree->n.sym->attr.function
+ && e->symtree->n.sym->attr.pointer)
+return true;
+
gfc_error ("%qs argument of %qs intrinsic at %L must be a variable",
gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
&e->where);
It's getting late...
[Bug fortran/100183] Segmentation fault at runtime when passing an internal procedure as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183 --- Comment #1 from anlauf at gcc dot gnu.org --- Cannot reproduce either with GNU Fortran (SUSE Linux) 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c] nor with GNU Fortran (GCC) 10.3.1 20210420 May need narrowing down to affected versions.
