[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90

["Tobias dot Schlueter at physik dot uni-muenchen dot de" <gcc-bugzilla@gcc.gnu.org>]

------- 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:
  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 :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203