I observed this for gfortran 4.3.2, but also just upgraded to 4.3.3, where only
the line number in gimplify.c increases by one.
The code is bad, I know, but the compiler should tell me that instead of
crashing, I guess.
A SuSE gfortran (version 4.1.2 20070115 (prerelease)) does correctly point out:
In file point_of_no_return.f95:20
face%bla => blu
1
Error: Pointer assignment to non-POINTER at (1)
While vanilla gfortran 4.3.3's response is an ICE, as noted in the
stripped-down example:
program point_of_no_return
implicit none
type face_t
! This is intended to be a pointer, but the keyword has been
forgotten...
integer :: bla
end type
integer, pointer :: blu
type(face_t), pointer :: face
allocate(face)
allocate(blu)
! Gfortran 4.3.2 gets ICE on this.
! It rather should detect that face%bla is no pointer (just a data field inside
a structure that is pointed to).
!point_of_no_return.f95: In function
'point_of_no_return':!point_of_no_return.f95:20: internal compiler error: in
gimplify_expr, at gimplify.c:6314
face%bla => blu
end program
--
Summary: ICE on invalid Fortran 95 code (bad pointer assignment),
gimplify_expr at gimplify.c:6315
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thomas dot orgis at awi dot de
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39931
