This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/46007] New: wrong code for SHAPE in a scalarized loop
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 13 Oct 2010 14:55:20 +0000
- Subject: [Bug fortran/46007] New: wrong code for SHAPE in a scalarized loop
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46007
Summary: wrong code for SHAPE in a scalarized loop
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: burnus@gcc.gnu.org
CC: mikael@gcc.gnu.org, arjen.markus@deltares.nl
Reported by Arjen at http://gcc.gnu.org/ml/fortran/2010-10/msg00153.html
Reduced test case:
integer, dimension(10) :: int1d
integer, dimension(:), pointer :: int1d_retrieved
allocate(int1d_retrieved(10))
if (any(shape(int1d_retrieved) /= shape(INT1D))) call abort()
end
It crashes (segfault) at run time for the IF condition.
First analysis:
struct array1_integer(kind=4) atmp.1;
atmp.1.dtype = 265;
atmp.1.data = 0B;
atmp.1.offset = 0;
D.1529 = &int1d_retrieved;
_gfortran_shape_4 (&atmp.1, D.1529);
The problem is that the bounds are not set - but _gfortran_shape tries to acces
the lbound/ubound via:
if (GFC_DESCRIPTOR_EXTENT(ret,0) < 1)
Additionally, it tries to set the value via:
ret->data[n * stride] = extent > 0 ? extent : 0 ;
which fails as ret->data alias "atmp.1.data" is not allocated.
Interestingly, if one uses:
tmp = shape(int1d_retrieved)
one has:
integer(kind=4) A.1[1];
atmp.0.dim[0].lbound = 0;
atmp.0.dim[0].ubound = 0;
atmp.0.data = (void * restrict) &A.1;
_gfortran_shape_4 (&atmp.0, D.1525);
which works. For some reason (scalarizer?) .data is not allocated/associated
and the bounds are not set for the first test case.