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

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

[corsepiu at gcc dot gnu dot org]

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

-- 
           Summary: Segfault while compiling
                    libgfortran/intrinsics/selected_int_kind.f90
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: corsepiu at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: h8300-rtems4.7


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-25 13:30 -------
Hmm.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build, ice-on-valid-code


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

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

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-04-25 14:33 -------
(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).

-- 


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

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

[kargl at gcc dot gnu dot org]

------- Additional Comments From kargl at gcc dot gnu dot org  2005-04-25 16:38 -------
(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.

-- 


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

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

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-04-25 17:14 -------
(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.





-- 


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

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

[ert at roe dot ac dot uk]

------- Additional Comments From ert at roe dot ac dot uk  2005-05-01 14:44 -------
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)



-- 


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

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

[ericw at evcohs dot com]

------- Additional Comments From ericw at evcohs dot com  2005-05-05 17:25 -------
(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

-- 


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

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

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2005-05-11 23:12 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobi at gcc dot gnu dot org


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

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

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-05-13 07:56 -------
Created an attachment (id=8884)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8884&action=view)
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


-- 


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

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

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-05-13 07:59 -------
Created an attachment (id=8885)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8885&action=view)
selected_int_kind.inc

Sorry, wrong file. This is the *.inc, Tobi requested.

-- 


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

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

[kargl at gcc dot gnu dot org]

------- Additional Comments From kargl at gcc dot gnu dot org  2005-05-13 18:48 -------
(In reply to comment #9)
> Created an attachment (id=8885)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8885&action=view)
> 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.

-- 


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

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

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2005-05-13 19:25 -------
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.

-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-13 20:34 -------
(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.

-- 


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

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

[kargl at gcc dot gnu dot org]

------- Additional Comments From kargl at gcc dot gnu dot org  2005-05-13 21:30 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu dot org


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

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

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-05-14 06:30 -------
(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.

-- 


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

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

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-05-14 07:00 -------
(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.



-- 


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

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

[Andrew Pinski]

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

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

[Andrew Pinski]

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

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

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-05-14 07:04 -------
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



-- 


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

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

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-05-14 07:08 -------
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



-- 


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

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

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-05-14 08:14 -------
(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.

-- 


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

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

[corsepiu at gcc dot gnu dot org]

------- 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.

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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joel at oarcorp dot com


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

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

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

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

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

[sgk at troutmask dot apl dot washington dot edu]

------- Additional Comments From sgk at troutmask dot apl dot washington dot edu  2005-05-14 15:57 -------
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



-- 


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

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

[sgk at troutmask dot apl dot washington dot edu]

------- Additional Comments From sgk at troutmask dot apl dot washington dot edu  2005-05-14 16:06 -------
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.



-- 


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

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

[corsepiu at gcc dot gnu dot org]

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

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

[Toon Moene]

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,

-- 
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
News on GNU Fortran 95: http://gfortran.org/

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

[toon at moene dot indiv dot nluug dot nl]

------- Additional Comments From toon at moene dot indiv dot nluug dot nl  2005-05-15 18:49 -------
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,



-- 


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

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

[joel at oarcorp dot com]

------- Additional Comments From joel at oarcorp dot com  2005-05-16 14:00 -------
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


-- 


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

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

[corsepiu at gcc dot gnu dot org]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-05-16 14:05 -------
(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.

-- 


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

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

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

------- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de  2005-05-18 11:21 -------
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.


-- 


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

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

[tobi at gcc dot gnu dot org]

------- Comment #28 from tobi at gcc dot gnu dot org  2006-02-12 18:47 -------
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;


-- 


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

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

[fxcoudert at gcc dot gnu dot org]

------- Comment #29 from fxcoudert at gcc dot gnu dot org  2006-09-25 09:19 -------
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


-- 


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