------- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-15
03:55 -------
(In reply to comment #20)
I think, I have isolated the bug:
BUG #1:
During bootstrap, libgfortran/Makefile tries to generate selected_int_kind.inc:
selected_int_kind.inc: $(srcdir)/mk-sik-inc.sh
$(SHELL) $(srcdir)/mk-sik-inc.sh '$(FCCOMPILE)' > $@
This fails due to a segfault in f951, but the Makefile does not halt on this
segfault and continues, leaving a corrupted selected_int_kind.inc behind.
The actual command that fails of part of running mk-sik-inc.sh is:
/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/f951
bla.f90 -quiet -dumpbase bla.f90 -auxbase bla -Wall -version -fno-repack-arrays
-fno-underscoring -o /tmp/cc6taI72.s
with this bla.f90 (The first code fragment being generated by mk-sik-inc.sh):
integer (kind=1) :: x
end
BUG #2
Debugging
f951 bla.f90 -quiet -dumpbase bla.f90 -auxbase bla -Wall -version
-fno-repack-arrays -fno-underscoring -o /tmp/cc6taI72.s
reveals this:
During its initialization, f951 calls gfc_init_kinds().
This succeeds to initialize all int types, but fails to find a mode for
kind=8/DIMode.
Near to its end it enters:
gfc_validate_kind (type=BT_REAL, kind=8, may_fail=0 '\0') at
../../gcc-4.0.0/gcc/fortran/trans-types.c:332
This fails (kind=8 N/A), therefore
gfc_internal_error("gfc_validate_kind(): Got bad kind")
is being entered, which calls
show_loci (&gfc_current_locus, NULL);
At this point, gfc_current_locus is
gdb) print gfc_current_locus
$24 = {nextc = 0x0, lb = 0x0}
With this value, show_loci dereferences a NULL pointer during computation of c1
at error.c:208:
198 show_loci (locus * l1, locus * l2)
199 {
200 int offset, flag, i, m, c1, c2, cmax;
201
202 if (l1 == NULL)
203 {
204 error_printf ("<During initialization>\n");
205 return;
206 }
207
208 c1 = l1->nextc - l1->lb->line;
209 c2 = 0;
(gdb) print *l1
$26 = {nextc = 0x0, lb = 0x0}
I.e. the origin of the segfault is show_loci's expectations not matching with
the actual contents of gfc_current_locus.
BUG #3:
libgfortran's configure should refuse to be compiled for setups not being
supported by it or silently degrade gracefully. IMO, simply not
compiling/disabling building libgfortran for such setups would be the simpliest
solutions
Note: I am not talking about disabing building fortran or libgfortran for whole
targets. For multilib'ed toolchains, libgfortran could be compilable/usable for
some multilib variants but not for all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
