[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |15.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed in gcc-15. Closing. Thanks for the report!
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 --- Comment #11 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:892304f1fe3e808b9f498353c144f1ae0591 commit r15-6925-g892304f1fe3e808b9f498353c144f1ae0591 Author: Harald Anlauf Date: Wed Jan 15 19:42:52 2025 +0100 Fortran: reject NULL as source-expr in ALLOCATE with SOURCE= or MOLD= [PR71884] PR fortran/71884 gcc/fortran/ChangeLog: * resolve.cc (resolve_allocate_expr): Reject intrinsic NULL as source-expr. gcc/testsuite/ChangeLog: * gfortran.dg/pr71884.f90: New test.
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #9) > Looks substantially like my patch from comment #6. ;-) I missed that one on the ML as it refers to a different PR number. > Another way to think about the problem is that > >allocate(x, source=null()) > > is equivalent to > >allocate(x) >x = null() > > which is nonsense for x an allocatable entity or pointer. That's what I thought, too. > Your patch is ok to commit with a suitable testcase. Will do. BTW: I figured that the testcase in comment#1 is dealt with by r8-5211-gd36eb6bf6d3e32 by you :-), so I'll leave out that case.
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 --- Comment #9 from kargls at comcast dot net --- (In reply to anlauf from comment #8) > Created attachment 60157 [details] > Patch > > This patch rejects NULL() as source-expr, without or with MOLD. > > I believe that F03:C632 can be interpreted as being incompatible with having > NULL() here. Intel ifx also rejects any such use I tried. > > (NAG first complains that the MOLD argument to NULL is missing, but when > provided, it crashes severely at runtime.) Looks substantially like my patch from comment #6. ;-) Another way to think about the problem is that allocate(x, source=null()) is equivalent to allocate(x) x = null() which is nonsense for x an allocatable entity or pointer. Your patch is ok to commit with a suitable testcase.
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 --- Comment #8 from anlauf at gcc dot gnu.org --- Created attachment 60157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60157&action=edit Patch This patch rejects NULL() as source-expr, without or with MOLD. I believe that F03:C632 can be interpreted as being incompatible with having NULL() here. Intel ifx also rejects any such use I tried. (NAG first complains that the MOLD argument to NULL is missing, but when provided, it crashes severely at runtime.)
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 --- Comment #7 from kargls at comcast dot net --- (In reply to anlauf from comment #5) > But all other variations, like in comment#0, ICE here. The code is comment #0 involves source-expr. The code in comment #1 involves type-spec. These are not variations; rather, two different bugs.
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884
--- Comment #6 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #4)
> (In reply to kargls from comment #3)
> > (In reply to Gerhard Steinmetz from comment #1)
> --- snip ---
> >
> > This now gives
> >
> > % gfcx -c pr71884.f90
> > pr71884.f90:4:25-31:
> >
> > 4 |allocate (character(*) :: z)
> > | 2 1
>
> I am still getting the ICE here. Steve, do you have a patch in there?
No patches. But, I do override GCC default build options and use
"-g -O" for all stages. I also have
% valgrind --leak-check=full -s ${PATH}/f951 a.f90
...
==10873==
==10873== HEAP SUMMARY:
==10873== in use at exit: 543,236 bytes in 2,904 blocks
==10873== total heap usage: 4,568 allocs, 1,664 frees, 1,667,111 bytes
allocated
==10873==
==10873== LEAK SUMMARY:
==10873==definitely lost: 0 bytes in 0 blocks
==10873==indirectly lost: 0 bytes in 0 blocks
==10873== possibly lost: 0 bytes in 0 blocks
==10873==still reachable: 541,508 bytes in 2,902 blocks
==10873== suppressed: 1,728 bytes in 2 blocks
==10873== Reachable blocks (those to which a pointer was found) are not shown.
==10873== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==10873==
==10873== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
--10873--
--10873-- used_suppression: 2 MEMCHECK-LIBTHR-REACHABLE-1
/usr/local/libexec/valgrind/default.supp:665 suppressed: 1,728 bytes in 2
blocks
==10873==
==10873== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
This is on FreeBSD, which does not use glibc. So, perhaps, an issue with
something coming out of libc (e.g., malloc).
Note, this bug report conflates issues with source-expr (i.e., those in
comment #0) and an invalid character type-spec (i.e., code in coment #1).
The patch in
https://gcc.gnu.org/pipermail/fortran/2025-January/061559.html
fixes the former. The latter seems to be fixed.
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #4) > (In reply to kargls from comment #3) > > (In reply to Gerhard Steinmetz from comment #1) > --- snip --- > > > > This now gives > > > > % gfcx -c pr71884.f90 > > pr71884.f90:4:25-31: > > > > 4 |allocate (character(*) :: z) > > | 2 1 > > I am still getting the ICE here. Steve, do you have a patch in there? Jerry, I am getting the following since gcc-8: pr71884-za.f90:3:25-30: allocate (character(*) :: z) 21 Error: Incompatible allocate-object at (1) for CHARACTER type-spec at (2) But all other variations, like in comment#0, ICE here.
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- (In reply to kargls from comment #3) > (In reply to Gerhard Steinmetz from comment #1) --- snip --- > > This now gives > > % gfcx -c pr71884.f90 > pr71884.f90:4:25-31: > > 4 |allocate (character(*) :: z) > | 2 1 I am still getting the ICE here. Steve, do you have a patch in there?
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 kargls at comcast dot net changed: What|Removed |Added CC||kargls at comcast dot net --- Comment #3 from kargls at comcast dot net --- (In reply to Gerhard Steinmetz from comment #1) > Another source position with obviously invalid code : > > > $ cat za.f90 > program p >character(:), allocatable :: z >allocate (character(*) :: z) > end > > > $ gfortran-7-20160710 za.f90 > za.f90:3:0: > > allocate (character(*) :: z) > > internal compiler error: in gfc_trans_allocate, at fortran/trans-stmt.c:5698 > 0x7a17f2 gfc_trans_allocate(gfc_code*) > ../../gcc/fortran/trans-stmt.c:5698 > 0x71bf87 trans_code > ../../gcc/fortran/trans.c:1838 > 0x74ac88 gfc_generate_function_code(gfc_namespace*) > ../../gcc/fortran/trans-decl.c:6171 > 0x6d6860 translate_all_program_units > ../../gcc/fortran/parse.c:5914 > 0x6d6860 gfc_parse_file() > ../../gcc/fortran/parse.c:6120 > 0x718d12 gfc_be_parse_file > ../../gcc/fortran/f95-lang.c:198 This now gives % gfcx -c pr71884.f90 pr71884.f90:4:25-31: 4 |allocate (character(*) :: z) | 2 1
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-15 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (7.0). Note that the ICE for 4.8 and 4.9 is pr71884.f90:3:0: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:106(4|5)
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 --- Comment #1 from Gerhard Steinmetz --- Another source position with obviously invalid code : $ cat za.f90 program p character(:), allocatable :: z allocate (character(*) :: z) end $ gfortran-7-20160710 za.f90 za.f90:3:0: allocate (character(*) :: z) internal compiler error: in gfc_trans_allocate, at fortran/trans-stmt.c:5698 0x7a17f2 gfc_trans_allocate(gfc_code*) ../../gcc/fortran/trans-stmt.c:5698 0x71bf87 trans_code ../../gcc/fortran/trans.c:1838 0x74ac88 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6171 0x6d6860 translate_all_program_units ../../gcc/fortran/parse.c:5914 0x6d6860 gfc_parse_file() ../../gcc/fortran/parse.c:6120 0x718d12 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
