From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15845 invoked by alias); 14 May 2005 15:25:21 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 15796 invoked by alias); 14 May 2005 15:25:17 -0000 Date: Sat, 14 May 2005 15:25:00 -0000 Message-ID: <20050514152517.15795.qmail@sourceware.org> From: "Tobias dot Schlueter at physik dot uni-muenchen dot de" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050425082043.21203.corsepiu@gcc.gnu.org> References: <20050425082043.21203.corsepiu@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 X-Bugzilla-Reason: CC X-SW-Source: 2005-05/txt/msg01901.txt.bz2 List-Id: ------- 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 : > 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