Several fortran tests using eoshift fail for SH. The typical one is
gfortran.dg/char_length_8.f90 -O0 execution test
and its reduced testcase is
CHARACTER(LEN=3), DIMENSION(10) :: Z
call test_eoshift
contains
subroutine test_eoshift
CHARACTER(LEN=1), DIMENSION(10) :: chk
chk(1:8) = "5"
chk(9:10) = " "
Z(:)="456"
if (any (EOSHIFT(Z(:)(2:2),2) .ne. chk)) call abort
END subroutine
END
It seems that a variable on stack is clobbered by the call of
_gfortran_eoshift0_4_char and it's resulting a segfault.
In .003t.original tree dump, that call
_gfortran_eoshift0_4_char (&atmp.8, 1, &atmp.4, &C.651, 0B, 0B, 1);
has 7 arguments, but it doesn't match with the prototype of
void \
eoshift0_##N##_char (gfc_array_char *ret, \
GFC_INTEGER_4 ret_length __attribute__((unused)), \
const gfc_array_char *array, \
const GFC_INTEGER_##N *pshift, \
const char *pbound, \
const GFC_INTEGER_##N *pdim, \
GFC_INTEGER_4 array_length, \
GFC_INTEGER_4 bound_length __attribute__((unused))) \
{ \
eoshift0 (ret, array, *pshift, pbound, pdim ? *pdim : 1, \
array_length, " ", 1); \
} \
in libgfortran/intrinsics/eoshift0.c which has 8 arguments.
Then the caller gives the stack area only for 7 arguments, but
the callee assumes the stack area is reserved for 8 arguments
and uses them for temporary purpose in the failing case.
--
Summary: [4.4 Regression] Some fortran tests using eoshift fail
on SH
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC target triplet: sh4-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
