During bootstrapping gcc-4.0.0 (release) with f95 enabled, this segfault occurs: #/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/gfortran -B/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/ -nostdinc -B/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/newlib/ -isystem /users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/newlib/targ-include -isystem /users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/newlib/libc/include -B/opt/rtems-4.7/h8300-rtems4.7/bin/ -B/opt/rtems-4.7/h8300-rtems4.7/lib/ -isystem /opt/rtems-4.7/h8300-rtems4.7/include -isystem /opt/rtems-4.7/h8300-rtems4.7/sys-include -Wall -fno-repack-arrays -fno-underscoring -c ../../../gcc-4.0.0/libgfortran/intrinsics/selected_int_kind.f90 -o selected_int_kind.o <built-in>:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make[1]: *** [selected_int_kind.lo] Error 1 gdb reveils this to be cause: Program received signal SIGSEGV, Segmentation fault. show_locus (offset=0, loc=0x833a17c) at ../../gcc-4.0.0/gcc/fortran/error.c:136 135 lb = loc->lb; 136 f = lb->file; With (gdb) print *loc $10 = {nextc = 0x0, lb = 0x0} I.e. a NULL pointer dereference in error.c:136
Hmm.
(In reply to comment #1) > Hmm. The origin of this issue seems to be f951's check's for REAL 8 (kind=8). The h8300 doesn't seem to provide this type and thereby seems to trigger a bug in f951's error handling. Bootstrapping avr-rtems w/ f95 enabled trips a similar or may-be the same bug (also a target which probably doesn't provide REAL 8).
(In reply to comment #2) > > The origin of this issue seems to be f951's check's for REAL 8 (kind=8). > > The h8300 doesn't seem to provide this type and thereby seems to trigger a bug > in f951's error handling. The Fortran standard mandates that if REAL(4) is the default real type, then there must be a REAL(8). I suspect gfortran will not/never supply a software implementation of REAL(8). We'll need to disable building of gfortran on targets that do not provide 2 floating point types.
(In reply to comment #3) > (In reply to comment #2) > > > > The origin of this issue seems to be f951's check's for REAL 8 (kind=8). > > > > The h8300 doesn't seem to provide this type and thereby seems to trigger a bug > > in f951's error handling. > > The Fortran standard mandates that if REAL(4) is the default > real type, then there must be a REAL(8). I suspect gfortran > will not/never supply a software implementation of REAL(8). > We'll need to disable building of gfortran on targets that > do not provide 2 floating point types. I guess you are aware that for multilib'ed OSes (such as RTEMS) there can be multilib variants for whom types exist and others for whom types might not exit. I.e. disabling certain targets in general would impose unnecessarily strict restrictions. IMO, it would be more reasonable, to provide a "graceful degradation" on those targets-variants.
Subject: New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 I get the same error compiling gcc-4.0.0 on an Opteron with Debian-3 (32-bit, glibc-2.2.5, 2.4.26 kernel) The failure occurs whether using gcc-2.95.4 or gcc-3.4.3 to start the bootstrap build. No problem building gcc-4.0.0 on an athlon-xp (homegrown linux, glibc-2.3.5, gcc-3.4.3, 2.6.11.7 kernel)
(In reply to comment #2) > Bootstrapping avr-rtems w/ f95 enabled trips a similar or may-be the same bug > (also a target which probably doesn't provide REAL 8). As a side note, it is known that Fortran does not build *at all* for the AVR target. AFAIK there has not been any work to provide Fortran for the AVR. This should be treated as a seperate issue. Thanks Eric
Can you attach the selected_int_kind.inc which is generated in the library build directory? Probably the problem can be reproduced on other platforms when trying to compile selected_int_kind.f90.
Created attachment 8884 [details] selected_int_kind.f90 As requested by Tobi, the selected_int_kind.f90 building h8300-rtems4.7 gcc-4.0.1 (pre 20050505) is ICE'ing on: /users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/gfortran -B/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/ -nostdinc -B/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/newlib/ -isystem /users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/newlib/targ-include -isystem /users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/newlib/libc/include -B/opt/rtems-4.7/h8300-rtems4.7/bin/ -B/opt/rtems-4.7/h8300-rtems4.7/lib/ -isystem /opt/rtems-4.7/h8300-rtems4.7/include -isystem /opt/rtems-4.7/h8300-rtems4.7/sys-include -Wall -fno-repack-arrays -fno-underscoring -c ../../../gcc-4.0.0/libgfortran/intrinsics/selected_int_kind.f90 -o selected_int_kind.o <built-in>:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [selected_int_kind.lo] Error 1 make[2]: Leaving directory `/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/libgfortran' make[1]: *** [all] Error 2 make[1]: Leaving directory `/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/libgfortran' make: *** [all-target-libgfortran] Error 2
Created attachment 8885 [details] selected_int_kind.inc Sorry, wrong file. This is the *.inc, Tobi requested.
(In reply to comment #9) > Created an attachment (id=8885) > selected_int_kind.inc > > Sorry, wrong file. This is the *.inc, Tobi requested. I see this failure on FreeBSD with my Dell laptop, which has a pentium 4 M processor. I've never been able to track done the cause of the problem. I can build gcc-4.x on FreeBSD with athlon and opteron processors without a problem.
Steve, are you saying that you're seeing the same failure on a Pentium 4 machine? This would be weird because ... Ralf, it looks like no working integer type is found when building the compiler. I'm out of town, so can't look at the source code right now, but I'm surprised that no assertion triggered in the compiler if this happens. RTH wrote this code, but I won't bother him about it before I can look at the source by the middle of next week.
(In reply to comment #11) > Steve, are you saying that you're seeing the same failure on a Pentium 4 > machine? This would be weird because ... Steve, I have heard that there are some GMP with bugs which could cause this, there was another PR about that.
Tobi and Andrew, Yes, I see this exact failure on FreeBSD with a pentium 4 M processor. I spent a few days hacking on Makefiles to turn on/off different compiler options and could never resolve the issues. I haven't tried bootstrapping 4.x on the laptop in several weeks because my amd64 system is much faster. :-) I'll try again this weekend with the version of GMP on the laptop and update GMP if it still fails. If you go to the GMP home page there is a VERY big warning about problems with gcc 4.0. In looking over the history of this PR, comment #2 through me off track because Fortran cannot be installed on a system with only a single REAL kind. I never connected the actual failure with my pentium 4 M experience.
(In reply to comment #11) > Ralf, it looks like no working integer type is found when building the compiler. The h8300 is special wrt. integer types: From a test script of mine: ... checking for char... yes checking size of char... 1 checking for short... yes checking size of short... 2 checking for int... yes checking size of int... 2 checking for long... yes checking size of long... 4 checking for long long... yes checking size of long long... 8 checking for float... yes checking size of float... 4 checking for double... yes checking size of double... 4 checking for long double... yes checking size of long double... 4 checking for void*... yes checking size of void*... 2 checking for int*... yes checking size of int*... 2 checking for long*... yes checking size of long*... 2 checking for __int8_t... yes checking size of __int8_t... 1 checking for __int16_t... yes checking size of __int16_t... 2 checking for __int32_t... yes checking size of __int32_t... 4 checking for __int64_t... yes checking size of __int64_t... 8 checking for int8_t... yes checking size of int8_t... 1 checking for int16_t... yes checking size of int16_t... 2 checking for int32_t... yes checking size of int32_t... 4 checking for int64_t... yes checking size of int64_t... 8 checking whether CHAR_BIT is declared... yes checking for bits in char... 8 Note: int8, int16, int32 and int64 all are available, it's just that the "usual" (bogus) assumptions * short==16bit * int==32bit * sizeof(void*)==sizeof(long) do not apply. Also note: This is a 16bit target, sizeof(void*)==16bit.
(In reply to comment #13) > I'll try again this weekend with the version of GMP on the laptop > and update GMP if it still fails. If you go to the GMP home page > there is a VERY big warning about problems with gcc 4.0. > > In looking over the history of this PR, comment #2 through me off > track because Fortran cannot be installed on a system with only a > single REAL kind. As I tried to express before, I think this PR actually trips several bugs at once. * A bug in error f95's handling, which probably causes the seg fault. The compiler simply must not seg fault. * A configuration problem: The configure scripts should be able to detect if a target doesn't meet its expectations. * f95 disqualifies ifselves from several embedded targets, if it can not be built/used on targets not supporting REAL8. IIRC, there even exist variants of major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. IMO, this is a design flaw, which should be in your interest to be circumvented.
Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: > * f95 disqualifies ifselves from several embedded targets, if it can > not be > built/used on targets not supporting REAL8. IIRC, there even exist > variants of > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > IMO, this is a design flaw, which should be in your interest to be > circumvented. Huh, PPC soft float supports REAL 8 still. -- Pinski
Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: > * f95 disqualifies ifselves from several embedded targets, if it can > not be > built/used on targets not supporting REAL8. IIRC, there even exist > variants of > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > IMO, this is a design flaw, which should be in your interest to be > circumvented. Also this is fortran requirement so technically it is not a design flaw in gfortran but in the standard, I would complain to them instead of to GCC about this. Yes we could circumvent this but that would be an extension. And who would be using fortran for embedded targets anyways. g77 had the same issue until at least a 3.3 (or so) was released so having it not fixed for a long time which was about 4 releases after the first official GCC with g77 support (2.95). -- Pinski
(In reply to comment #17) > Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 > > > On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: > > > * f95 disqualifies ifselves from several embedded targets, if it can > > not be > > built/used on targets not supporting REAL8. IIRC, there even exist > > variants of > > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > > IMO, this is a design flaw, which should be in your interest to be > > circumvented. > > > Also this is fortran requirement so technically it is not a design flaw > in gfortran but in the standard, I would complain to them instead of to > GCC about this. Yes we could circumvent this but that would be an extension. Free free to hang on closely to standards ... to me, this sounds as being stubborn and non-helpful to the fortran community, nor to GCC nor to embedded systems. I'd prefer GCC to hang on to practical demands and implications stemming from practice instead of being religious about standards ignoring practical implications. > And who would be using fortran for embedded targets anyways. Consider numerical applications on embedded systems using fortran libraries (image processing, control applications etc.) IMO, this is a hen-and-egg problem. Hardly anybody is using fortran on embedded targets because the language is not available for many targets, and it is not available for many targets, because the language is not able to support them/is too non-portable. In this particular case, I fail to understand why REAL8 must be available and I fail to understand why this type can't be made conditionally available. > g77 had the same issue until at least a 3.3 (or so) was released so having it > not fixed for a long time which was about 4 releases after the first official > GCC with g77 support (2.95). Well, you know, gcc-4.0.0 is a major GCC release, gfortran is new ... All this had caused me to have a look at known weeknesses in GCC. The result (not limited to fortran) esp. wrt. embedded targets, is pretty disillusioning.
(In reply to comment #16) > Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 > > > On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: > > > * f95 disqualifies ifselves from several embedded targets, if it can > > not be > > built/used on targets not supporting REAL8. IIRC, there even exist > > variants of > > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > > IMO, this is a design flaw, which should be in your interest to be > > circumvented. > > Huh, PPC soft float supports REAL 8 still. Joel, do you recall the target in RTEMS which has 4-byte floats only? (We recently had an issue with it floating point context sizes related to it? IIRC, it had been a powerpc variant and we were forced to drop it because GCC doesn't support it. BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't have 8byte floats. RTEMS doesn't support them, so I've never tried to build fortran for then.
Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 Quoting corsepiu at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>: > As I tried to express before, I think this PR actually trips several bugs at > once. > > * A bug in error f95's handling, which probably causes the seg fault. The > compiler simply must not seg fault. Exactly, I assume this has to do with the fact that we're trying to initialize a zero-length parameter array, which is somewhat unusual, and thus probably not well-tested and buggy. I won't have access to my box, but if someone has a few spare minutes, I'd suggest he tries this code: INTEGER, PARAMETER :: i(0) = (/ /) or, if this doesn't break, TYPE a INTEGER i END TYPE a TYPE(a), PARAMETER :: i(0) = (/ /) I'm fairly sure that this will give the same segfault Ralf is seeing. > * A configuration problem: The configure scripts should be able to detect if > a > target doesn't meet its expectations. While this is true, this is not necessarily a compile-time problem. the mapping between the compiler's internal types and Fortran types is made at execution time of the compiler. > * f95 disqualifies ifselves from several embedded targets, if it can not be > built/used on targets not supporting REAL8. IIRC, there even exist variants > of > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > IMO, this is a design flaw, which should be in your interest to be > circumvented. Fortran requires that there be a floating point type (DOUBLE PRECISION) which takes twice the space of the usual REAL variables. It should probably be possible to use gfortran on platforms which don't have this, but given the amount of Fortran code that is tied to this assumption, I don't think this would be worthwhile. E.g. COMMON block layout depends crucially on this. But the bug we're dealing with has to do with INTEGER kinds, once we've cleared the issues WRT those, we can have this discussion again. Unless everything unxepectedly works out of the box :-)
Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 On Sat, May 14, 2005 at 03:25:17PM -0000, Tobias dot Schlueter at physik dot uni-muenchen dot de wrote: > > Fortran requires that there be a floating point type (DOUBLE PRECISION) which > takes twice the space of the usual REAL variables. It should probably be > possible to use gfortran on platforms which don't have this, but given the > amount of Fortran code that is tied to this assumption, I don't think this > would be worthwhile. E.g. COMMON block layout depends crucially on this. > Yep. We can't forget about our friend EQUIVALENCE
Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 On Sat, May 14, 2005 at 08:14:48AM -0000, corsepiu at gcc dot gnu dot org wrote: > > Free free to hang on closely to standards ... to me, this sounds as being > stubborn and non-helpful to the fortran community, nor to GCC nor to embedded > systems. I'd prefer GCC to hang on to practical demands and implications > stemming from practice instead of being religious about standards ignoring > practical implications. > Dealing with vendor extensions are one of the top topic on comp.lang.fortran. gfortran currently implements about 90-95% of the standardize language. Those of us who actively work on gfortran will probably use our time to implement Fortran not some vendor extension that less than 0.01% of gfortran users need.
(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.
Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org wrote: > Joel, do you recall the target in RTEMS which has 4-byte floats only? > (We recently had an issue with it floating point context sizes related to it? > IIRC, it had been a powerpc variant and we were forced to drop it because GCC > doesn't support it. > > BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't > have 8byte floats. RTEMS doesn't support them, so I've never tried to build > fortran for then. Note that the major demand the Fortran Standard places on DOUBLE PRECISION is that it takes up twice the amount of storage. It also is supposed to be of "higher precision", but that is a QOI issue. Cheers,
Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org wrote: > ------- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14 08:33 ------- > (In reply to comment #16) > >>Subject: Re: Segfault while compiling > > libgfortran/intrinsics/selected_int_kind.f90 > >> >>On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: >> >> >>>* f95 disqualifies ifselves from several embedded targets, if it can >>>not be >>>built/used on targets not supporting REAL8. IIRC, there even exist >>>variants of >>>major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. >>>IMO, this is a design flaw, which should be in your interest to be >>>circumvented. >> >>Huh, PPC soft float supports REAL 8 still. > > > Joel, do you recall the target in RTEMS which has 4-byte floats only? > (We recently had an issue with it floating point context sizes related to it? > IIRC, it had been a powerpc variant and we were forced to drop it because GCC > doesn't support it. I don't know of any specific models. The code in RTEMS was based upon an early (mid-90's) version of the PowerPC Programming Environments Manual. I recall that version of the manual as being clear that a single precision PowerPC was possible within the architectural definition. I just downloaded the current one from FreeScale and I see no hint that this architectural option is allowed anymore. > BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't > have 8byte floats. RTEMS doesn't support them, so I've never tried to build > fortran for then. --joel
(In reply to comment #24) > Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 > > corsepiu at gcc dot gnu dot org wrote: > > > Joel, do you recall the target in RTEMS which has 4-byte floats only? I've found it. The RTEMS sources claim the "PowerPC 602" to have 4byte floats, only. > Note that the major demand the Fortran Standard places on DOUBLE > PRECISION is that it takes up twice the amount of storage. It also is > supposed to be of "higher precision", but that is a QOI issue. Cf. gcc-4.0-branch/fortran/trans-types.c ca. line 228ff: /* F95 14.6.3.1: A nonpointer scalar object of type double precision real ... occupies two contiguous numeric storage units. ... .. But at present there are no GCC targets for which a two-word type does not exist, so we just let gfc_validate_kind abort and tell us if something breaks. */ Well, the h8300 has 8byte types (seemingly long long), but it doesn't have 8byte floats. As the comment is on REAL8, ... there is something fishy in there.
Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 Tobias dot Schlueter at physik dot uni-muenchen dot de wrote: > ------- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-05-14 15:25 ------- > Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 > > Quoting corsepiu at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>: > >>As I tried to express before, I think this PR actually trips several bugs at >>once. >> >>* A bug in error f95's handling, which probably causes the seg fault. The >>compiler simply must not seg fault. > > > Exactly, I assume this has to do with the fact that we're trying to initialize a > zero-length parameter array, which is somewhat unusual, and thus probably not > well-tested and buggy. > > I won't have access to my box, but if someone has a few spare minutes, I'd > suggest he tries this code: This did work correctly, so that's one possible problem less.
Ralf, this patch should fix the segfault, it shouldn't give you a working compiler, though. Index: error.c =================================================================== --- error.c (revision 110873) +++ error.c (working copy) @@ -199,7 +199,7 @@ show_loci (locus * l1, locus * l2) { int offset, flag, i, m, c1, c2, cmax; - if (l1 == NULL) + if (!l1 || !l1->lb) { error_printf ("<During initialization>\n"); return;
Subject: Bug 21203 Author: fxcoudert Date: Mon Sep 25 09:19:36 2006 New Revision: 117191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117191 Log: PR fortran/21203 * error.c (show_loci): No need to risk an ICE to output a slightly nicer error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c
Changing the summary of this bug to reflect the actual problem. Downgrading to enhancement because it would be a weird GNU extension. And unless someone show real interest in gfortran working on these platforms and provides access to a test system, I don't think we'd implement a graceful degradation soon.
Closing as WONTFIX. See http://gcc.gnu.org/ml/fortran/2009-04/msg00149.html for discussion.