------- Comment #8 from burnus at gcc dot gnu dot org 2007-02-15 09:45 -------
The link to c.l.fortran is:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/23aa68ecce460e50
Richard Main: "The pointer assignment is ok. I [...] don't have
time to adequately peruse the rest of the code. [...]
I do note that you've got generics that have specifics of the same name
as the generic. The standard does allow that, but it wouldn't shock me
if some compilers get as confused by it as I do."
Both the initial and the reduced program compile and run (seemingly) correctly
with NAG f95 5.1, ifort 9.1 and 10, and sunf95 8.3.
I played around with my reduced testcase (attachment 13050). The crash only
occurs with:
type mesh
integer,allocatable :: area(:)
end type mesh
if I replace it by "pointer :: area(:)" it does not crash. The extra lines in
msh_ and get_scalar_field_msh are:
__result_msh_->area.data = 0B;
and
__result_get_scalar_field_msh->area.data = 0B;
Actually, the program does not crash if one replaces the third line of:
function msh_(fld)
type(mesh), pointer :: msh_
type(field), intent(in) :: fld
msh_ => fld%msh
end function msh_
by
type(field), TARGET, intent(in) :: fld
I have still to re-read the test case to check whether TARGET is required by
the standard in this case or not. Adding "target" to msh_ is however not enough
to prevent the original test case (attachment 13049) from crashing in
get_scalar_field_msh; here the dump-tree-original looks like:
struct mesh * __result_get_scalar_field_msh;
__result_get_scalar_field_msh->area.data = 0B;
__result_get_scalar_field_msh->dist.data = 0B;
__result_get_scalar_field_msh->interp.data = 0B;
I don't know whether something happens behind the scenes, but accessing a
component of a (non-allocated and non-associated) pointer sounds bad.
Especially, even if it worked, setting them to values and then overwriting them
by
__result_get_scalar_field_msh = msh_ (&fld->base);
seems to be strange.
I therefore think there are two bugs:
a) In the program a TARGET is missing
b) In gfortran one should not initialize array components of pointers before
the pointer is allocated (if it is associated it is not needed). If the
gfortran bug is fixed, (a) is probably not needed to prevent the crash.
(Next step: check whether the standard mandates TARGET and where the bug in
gfortran is located, must be somewhere in trans-*.c.)
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu dot
| |org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet|i686-pc-linux-gnu |
Keywords| |wrong-code
Last reconfirmed|0000-00-00 00:00:00 |2007-02-15 09:45:54
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
