[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Jakub Jelinek --- Fixed.
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #17 from Jakub Jelinek --- Author: jakub Date: Sat Dec 8 13:37:49 2018 New Revision: 266907 URL: https://gcc.gnu.org/viewcvs?rev=266907=gcc=rev Log: PR fortran/88304 * tree-nested.c (convert_local_reference_stmt): Handle clobbers where lhs is not a decl normally, don't call use_pointer_in_frame on that lhs. * gfortran.fortran-torture/compile/pr88304-2.f90: New test. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr88304-2.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-nested.c
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- Created attachment 45181 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45181=edit gcc9-pr88304.patch Untested fix for the #c15 bug (a different one from the originally reported).
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #15 from Harald Anlauf --- (In reply to Jakub Jelinek from comment #14) > Author: jakub > Date: Thu Dec 6 10:28:31 2018 > New Revision: 266847 > > URL: https://gcc.gnu.org/viewcvs?rev=266847=gcc=rev This fixes the original testcase, but not the following variant, which crashes with a similar backtrace: MODULE mo_occ implicit none integer :: ncid contains function nf90_inquire_dimension(ncid, dimid, name, len) integer,intent( in) :: ncid, dimid character(*), optional, intent(out) :: name integer, optional, intent(out) :: len integer :: nf90_inquire_dimension end function nf90_inquire_dimension subroutine read_gpsro_netcdf () contains function dimlen (dim) integer ,intent(in) :: dim integer :: dimlen integer :: status integer :: dimids (10) status = nf90_Inquire_Dimension (ncid, dimids(dim), len=dimlen) end function dimlen end subroutine read_gpsro_netcdf end module mo_occ % gfc-trunk -c gfcbug152-v3.f90 gfcbug152-v3.f90:11:0: 11 | subroutine read_gpsro_netcdf () | internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'mem_ref' in use_pointer_in_frame, at tree-nested.c:267 0x5ed193 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../trunk/gcc/tree.c:9929 0xd44250 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../trunk/gcc/tree.h:3271 0xd44250 use_pointer_in_frame ../../trunk/gcc/tree-nested.c:267 0xd4a745 convert_local_reference_stmt ../../trunk/gcc/tree-nested.c:2327 0x9d8a56 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:568 0x9d8c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:51 0x9d8bb1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:631 0x9d8c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:51 0x9d8b11 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:595 0x9d8c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../trunk/gcc/gimple-walk.c:51 0xd440c8 walk_body ../../trunk/gcc/tree-nested.c:703 0xd44118 walk_function ../../trunk/gcc/tree-nested.c:714 0xd44118 walk_all_functions ../../trunk/gcc/tree-nested.c:779 0xd4e094 lower_nested_functions(tree_node*) ../../trunk/gcc/tree-nested.c:3482 0x836330 cgraph_node::analyze() ../../trunk/gcc/cgraphunit.c:673 0x8397b9 analyze_functions ../../trunk/gcc/cgraphunit.c:1126 0x83a8a2 symbol_table::finalize_compilation_unit() ../../trunk/gcc/cgraphunit.c:2835
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Thu Dec 6 10:28:31 2018 New Revision: 266847 URL: https://gcc.gnu.org/viewcvs?rev=266847=gcc=rev Log: PR fortran/88304 * tree-nested.c (convert_nonlocal_reference_stmt): Remove clobbers for non-local automatic decls. * gfortran.fortran-torture/compile/pr88304.f90: New test. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr88304.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-nested.c
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #13 from Jakub Jelinek --- Created attachment 45158 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45158=edit gcc9-pr88304.patch Untested fix for the tree-nested.c bug, handles it like we handle it in convert_local_reference_stmt.
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #12 from rguenther at suse dot de ---
On Wed, 5 Dec 2018, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
>
> --- Comment #11 from rguenther at suse dot de ---
> On Wed, 5 Dec 2018, jakub at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
> >
> > --- Comment #10 from Jakub Jelinek ---
> > And lastly, what tree-nested.c does in cases which don't really fail is
> > pretty
> > weird:
> > module pr88304
> > implicit none
> > contains
> > subroutine f1 (x)
> > integer, intent(out) :: x
> > x = 5
> > end subroutine f1
> > subroutine f2 ()
> > integer :: x
> > call f3
> > if (x .ne. 5) stop 1
> > contains
> > subroutine f3
> > call f1 (x)
> > end subroutine f3
> > end subroutine f2
> > end module pr88304
> >
> > The original
> > x = {CLOBBER};
> > is replaced here with:
> > integer(kind=4) D.3863;
> >
> > D.3863 = {CLOBBER};
> > CHAIN.3->x = D.3863;
> > I guess we want to drop those from the IL instead as well.
>
> Heh, yes. Or convert them to
>
> D.3863 = CHAIN.3->x;
> *D.3863 = {CLOBBER};
>
> but not sure if those will ever end up being useful.
Might be in case the function is inlined if we manage to turn
it back to
x = {CLOBBER};
?
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #11 from rguenther at suse dot de ---
On Wed, 5 Dec 2018, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
>
> --- Comment #10 from Jakub Jelinek ---
> And lastly, what tree-nested.c does in cases which don't really fail is pretty
> weird:
> module pr88304
> implicit none
> contains
> subroutine f1 (x)
> integer, intent(out) :: x
> x = 5
> end subroutine f1
> subroutine f2 ()
> integer :: x
> call f3
> if (x .ne. 5) stop 1
> contains
> subroutine f3
> call f1 (x)
> end subroutine f3
> end subroutine f2
> end module pr88304
>
> The original
> x = {CLOBBER};
> is replaced here with:
> integer(kind=4) D.3863;
>
> D.3863 = {CLOBBER};
> CHAIN.3->x = D.3863;
> I guess we want to drop those from the IL instead as well.
Heh, yes. Or convert them to
D.3863 = CHAIN.3->x;
*D.3863 = {CLOBBER};
but not sure if those will ever end up being useful.
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #10 from Jakub Jelinek ---
And lastly, what tree-nested.c does in cases which don't really fail is pretty
weird:
module pr88304
implicit none
contains
subroutine f1 (x)
integer, intent(out) :: x
x = 5
end subroutine f1
subroutine f2 ()
integer :: x
call f3
if (x .ne. 5) stop 1
contains
subroutine f3
call f1 (x)
end subroutine f3
end subroutine f2
end module pr88304
The original
x = {CLOBBER};
is replaced here with:
integer(kind=4) D.3863;
D.3863 = {CLOBBER};
CHAIN.3->x = D.3863;
I guess we want to drop those from the IL instead as well.
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #9 from Jakub Jelinek ---
I'll fix the tree-nested.c issue, but I'm wondering about the clobber. E.g.
for
module pr88304
implicit none
type t
integer :: b = -1
integer :: c = 2
end type t
contains
subroutine f1 (x)
integer, intent(out) :: x
x = 5
end subroutine f1
subroutine f4 (x)
integer, intent(in) :: x
end subroutine f4
subroutine f2 ()
type(t) :: x
call f3
if (x%b .ne. 5) stop 1
contains
subroutine f3
call f1 (x%b)
end subroutine f3
subroutine f5
call f4 (x%b)
end subroutine f5
end subroutine f2
end module pr88304
the clobber at the beginning of f3 doesn't make sense to me:
f3 ()
{
x = {CLOBBER};
_1 =
f1 (_1);
}
Does the fact that you call f1 (x%b) and f1's argument is intent(in) clobber
the whole type, including x%c? I'd expect only x%b to be clobbered.
Or consider:
module pr88304
implicit none
type t
integer :: b = -1
integer :: c = 2
end type t
contains
subroutine f1 (x)
integer, intent(out) :: x
x = 5
end subroutine f1
subroutine f2 ()
type(t) :: x
call f1 (x%b)
if (x%b .ne. 5 .or. x%c .ne. 2) stop 1
end subroutine f2
end module pr88304
use pr88304
call f2
end
This fails at -O2, is it really undefined?
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #8 from Jakub Jelinek --- Reduced testcase: module pr88304 implicit none type t integer :: b = -1 end type t contains subroutine f1 (x) integer (kind = 4), intent(out) :: x x = 5 end subroutine f1 subroutine f2 () type(t) :: x call f3 if (x%b .ne. 5) stop 1 contains subroutine f3 call f1 (x%b) end subroutine f3 end subroutine f2 end module pr88304
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #7 from Harald Anlauf --- (In reply to kargl from comment #6) > (In reply to Harald Anlauf from comment #5) > > > > A derived type with component initialization (like t_fileinfo) should > > implicitly get the SAVE attribute, which appears to be lost here. > > Adding it explicitly removes the ICE. Thus a front-end issue? > > The F2018 standard (n2146.pdf, p. 78) says > > Explicit initialization in a type declaration statement (8.2) > overrides default initialization (see NOTE 7.32). Unlike explicit > initialization, default initialization does not imply that the object > has the SAVE attribute. > > HTH Thanks for pointing this out. And replacing type(t_fileinfo), save :: gattr ! No ICE by type(t_fileinfo) :: gattr = t_fileinfo() ! No ICE produces identical code. So I take back the possible wrong-code issue. Only the ICE remains.
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to Harald Anlauf from comment #5) > > A derived type with component initialization (like t_fileinfo) should > implicitly get the SAVE attribute, which appears to be lost here. > Adding it explicitly removes the ICE. Thus a front-end issue? The F2018 standard (n2146.pdf, p. 78) says Explicit initialization in a type declaration statement (8.2) overrides default initialization (see NOTE 7.32). Unlike explicit initialization, default initialization does not imply that the object has the SAVE attribute. HTH
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #5 from Harald Anlauf ---
(In reply to Richard Biener from comment #4)
> Confirmed. We do not expect
>
> CHAIN.10->gattr = {CLOBBER};
>
> I believe the FE inserts these now to better share stack slots:
Thanks for pointing to the gimple. Looking at it with my zero knowledge,
it looks in addition to a wrong code issue. With this is mind, I further
reduced the complete testcase to this:
MODULE mo_feedbk
implicit none
type t_fileinfo
integer :: nex = -1
integer :: pad = 0
end type t_fileinfo
interface nf90_get_att
module procedure nf90_get_att_one_FourByteInt
end interface
contains
function nf90_get_att_one_FourByteInt(ncid, varid, name, values)
integer, intent( in) :: ncid, varid
character(len=*), intent( in) :: name
integer , intent(out) :: values
integer :: nf90_get_att_one_FourByteInt
end function nf90_get_att_one_FourByteInt
subroutine convert_cof ()
integer:: dummy = -1
! type(t_fileinfo), save :: gattr ! No ICE
type(t_fileinfo) :: gattr ! ICE
contains
subroutine open_input
integer :: rc
rc = nf90_get_att (0, 0, "experiment", dummy ) ! OK
rc = nf90_get_att (0, 0, "experiment", gattr%nex ) ! ICE
end subroutine open_input
end subroutine convert_cof
end module mo_feedbk
A derived type with component initialization (like t_fileinfo) should
implicitly get the SAVE attribute, which appears to be lost here.
Adding it explicitly removes the ICE. Thus a front-end issue?
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
CC||jakub at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
Confirmed. We do not expect
CHAIN.10->gattr = {CLOBBER};
I believe the FE inserts these now to better share stack slots:
open_input ()
{
{
static integer(kind=4) C.3884 = 0;
integer(kind=4) D.3887;
gattr = {CLOBBER};
D.3887 = nf90_get_att_one_fourbyteint (, , &"experiment"[1]{lb:
1 sz: 1}, , 10);
chk (, 0B);
}
}
And the issue is that we transform these into
CHAIN.10->gattr = {CLOBBER};
which isn't valid GIMPLE. Now we can drop the nonlocal clobbers on the floor
(easy) or if we want to re-gimplify this into
ptr = >gattr;
*ptr = {CLOBBER};
dropping it would eventually be possible in convert_nonlocal_reference_op
via wi->gsi.
Jakub?
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #3 from Harald Anlauf --- Created attachment 45147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45147=edit Minimal netcdf-fortran part for the reproducer Compile the netcdf.f90 header before the testcase.
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 Status|UNCONFIRMED |WAITING Last reconfirmed||2018-12-03 Ever confirmed|0 |1
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #2 from Richard Biener --- waiting for self-contained testcase
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #1 from Harald Anlauf --- No special options used, just: % gfc-trunk -c -I/opt/gcc/9/pkg/netcdf/include gfcbug152.f90 (where above path hold the gfortran-9 specific netcdf.mod & friends).
