* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
@ 2005-04-25 13:33 ` pinskia at gcc dot gnu dot org
2005-04-25 14:34 ` corsepiu at gcc dot gnu dot org
` (26 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-04-25 13:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
2005-04-25 13:33 ` [Bug fortran/21203] " pinskia at gcc dot gnu dot org
@ 2005-04-25 14:34 ` corsepiu at gcc dot gnu dot org
2005-04-25 16:38 ` kargl at gcc dot gnu dot org
` (25 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: corsepiu at gcc dot gnu dot org @ 2005-04-25 14:34 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
2005-04-25 13:33 ` [Bug fortran/21203] " pinskia at gcc dot gnu dot org
2005-04-25 14:34 ` corsepiu at gcc dot gnu dot org
@ 2005-04-25 16:38 ` kargl at gcc dot gnu dot org
2005-04-25 17:15 ` corsepiu at gcc dot gnu dot org
` (24 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: kargl at gcc dot gnu dot org @ 2005-04-25 16:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (2 preceding siblings ...)
2005-04-25 16:38 ` kargl at gcc dot gnu dot org
@ 2005-04-25 17:15 ` corsepiu at gcc dot gnu dot org
2005-05-01 14:44 ` ert at roe dot ac dot uk
` (23 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: corsepiu at gcc dot gnu dot org @ 2005-04-25 17:15 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (3 preceding siblings ...)
2005-04-25 17:15 ` corsepiu at gcc dot gnu dot org
@ 2005-05-01 14:44 ` ert at roe dot ac dot uk
2005-05-05 17:25 ` ericw at evcohs dot com
` (22 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: ert at roe dot ac dot uk @ 2005-05-01 14:44 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (4 preceding siblings ...)
2005-05-01 14:44 ` ert at roe dot ac dot uk
@ 2005-05-05 17:25 ` ericw at evcohs dot com
2005-05-11 23:12 ` tobi at gcc dot gnu dot org
` (21 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: ericw at evcohs dot com @ 2005-05-05 17:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (5 preceding siblings ...)
2005-05-05 17:25 ` ericw at evcohs dot com
@ 2005-05-11 23:12 ` tobi at gcc dot gnu dot org
2005-05-13 7:56 ` corsepiu at gcc dot gnu dot org
` (20 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: tobi at gcc dot gnu dot org @ 2005-05-11 23:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (6 preceding siblings ...)
2005-05-11 23:12 ` tobi at gcc dot gnu dot org
@ 2005-05-13 7:56 ` corsepiu at gcc dot gnu dot org
2005-05-13 7:59 ` corsepiu at gcc dot gnu dot org
` (19 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: corsepiu at gcc dot gnu dot org @ 2005-05-13 7:56 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (7 preceding siblings ...)
2005-05-13 7:56 ` corsepiu at gcc dot gnu dot org
@ 2005-05-13 7:59 ` corsepiu at gcc dot gnu dot org
2005-05-13 18:48 ` kargl at gcc dot gnu dot org
` (18 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: corsepiu at gcc dot gnu dot org @ 2005-05-13 7:59 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (8 preceding siblings ...)
2005-05-13 7:59 ` corsepiu at gcc dot gnu dot org
@ 2005-05-13 18:48 ` kargl at gcc dot gnu dot org
2005-05-13 19:25 ` tobi at gcc dot gnu dot org
` (17 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: kargl at gcc dot gnu dot org @ 2005-05-13 18:48 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (9 preceding siblings ...)
2005-05-13 18:48 ` kargl at gcc dot gnu dot org
@ 2005-05-13 19:25 ` tobi at gcc dot gnu dot org
2005-05-13 20:34 ` pinskia at gcc dot gnu dot org
` (16 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: tobi at gcc dot gnu dot org @ 2005-05-13 19:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (10 preceding siblings ...)
2005-05-13 19:25 ` tobi at gcc dot gnu dot org
@ 2005-05-13 20:34 ` pinskia at gcc dot gnu dot org
2005-05-13 21:30 ` kargl at gcc dot gnu dot org
` (15 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-05-13 20:34 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (11 preceding siblings ...)
2005-05-13 20:34 ` pinskia at gcc dot gnu dot org
@ 2005-05-13 21:30 ` kargl at gcc dot gnu dot org
2005-05-14 6:30 ` corsepiu at gcc dot gnu dot org
` (14 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: kargl at gcc dot gnu dot org @ 2005-05-13 21:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (12 preceding siblings ...)
2005-05-13 21:30 ` kargl at gcc dot gnu dot org
@ 2005-05-14 6:30 ` corsepiu at gcc dot gnu dot org
2005-05-14 7:00 ` corsepiu at gcc dot gnu dot org
` (13 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: corsepiu at gcc dot gnu dot org @ 2005-05-14 6:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (13 preceding siblings ...)
2005-05-14 6:30 ` corsepiu at gcc dot gnu dot org
@ 2005-05-14 7:00 ` corsepiu at gcc dot gnu dot org
2005-05-14 7:04 ` Andrew Pinski
2005-05-14 7:08 ` Andrew Pinski
2005-05-14 7:04 ` pinskia at physics dot uc dot edu
` (12 subsequent siblings)
27 siblings, 2 replies; 33+ messages in thread
From: corsepiu at gcc dot gnu dot org @ 2005-05-14 7:00 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-05-14 7:00 ` corsepiu at gcc dot gnu dot org
@ 2005-05-14 7:04 ` Andrew Pinski
2005-05-14 7:08 ` Andrew Pinski
1 sibling, 0 replies; 33+ messages in thread
From: Andrew Pinski @ 2005-05-14 7:04 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-05-14 7:00 ` corsepiu at gcc dot gnu dot org
2005-05-14 7:04 ` Andrew Pinski
@ 2005-05-14 7:08 ` Andrew Pinski
1 sibling, 0 replies; 33+ messages in thread
From: Andrew Pinski @ 2005-05-14 7:08 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (14 preceding siblings ...)
2005-05-14 7:00 ` corsepiu at gcc dot gnu dot org
@ 2005-05-14 7:04 ` pinskia at physics dot uc dot edu
2005-05-14 7:08 ` pinskia at physics dot uc dot edu
` (11 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: pinskia at physics dot uc dot edu @ 2005-05-14 7:04 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (15 preceding siblings ...)
2005-05-14 7:04 ` pinskia at physics dot uc dot edu
@ 2005-05-14 7:08 ` pinskia at physics dot uc dot edu
2005-05-14 8:14 ` corsepiu at gcc dot gnu dot org
` (10 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: pinskia at physics dot uc dot edu @ 2005-05-14 7:08 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (16 preceding siblings ...)
2005-05-14 7:08 ` pinskia at physics dot uc dot edu
@ 2005-05-14 8:14 ` corsepiu at gcc dot gnu dot org
2005-05-14 8:34 ` corsepiu at gcc dot gnu dot org
` (9 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: corsepiu at gcc dot gnu dot org @ 2005-05-14 8:14 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (17 preceding siblings ...)
2005-05-14 8:14 ` corsepiu at gcc dot gnu dot org
@ 2005-05-14 8:34 ` corsepiu at gcc dot gnu dot org
2005-05-14 15:25 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
` (8 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: corsepiu at gcc dot gnu dot org @ 2005-05-14 8:34 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (18 preceding siblings ...)
2005-05-14 8:34 ` corsepiu at gcc dot gnu dot org
@ 2005-05-14 15:25 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-05-14 15:58 ` sgk at troutmask dot apl dot washington dot edu
` (7 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: Tobias dot Schlueter at physik dot uni-muenchen dot de @ 2005-05-14 15:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (19 preceding siblings ...)
2005-05-14 15:25 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
@ 2005-05-14 15:58 ` sgk at troutmask dot apl dot washington dot edu
2005-05-14 16:06 ` sgk at troutmask dot apl dot washington dot edu
` (6 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: sgk at troutmask dot apl dot washington dot edu @ 2005-05-14 15:58 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (20 preceding siblings ...)
2005-05-14 15:58 ` sgk at troutmask dot apl dot washington dot edu
@ 2005-05-14 16:06 ` sgk at troutmask dot apl dot washington dot edu
2005-05-15 3:55 ` corsepiu at gcc dot gnu dot org
` (5 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: sgk at troutmask dot apl dot washington dot edu @ 2005-05-14 16:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (21 preceding siblings ...)
2005-05-14 16:06 ` sgk at troutmask dot apl dot washington dot edu
@ 2005-05-15 3:55 ` corsepiu at gcc dot gnu dot org
2005-05-15 18:49 ` toon at moene dot indiv dot nluug dot nl
` (4 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: corsepiu at gcc dot gnu dot org @ 2005-05-15 3:55 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (22 preceding siblings ...)
2005-05-15 3:55 ` corsepiu at gcc dot gnu dot org
@ 2005-05-15 18:49 ` toon at moene dot indiv dot nluug dot nl
[not found] ` <12687093.1116061034131.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net>
` (3 subsequent siblings)
27 siblings, 0 replies; 33+ messages in thread
From: toon at moene dot indiv dot nluug dot nl @ 2005-05-15 18:49 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <12687093.1116061034131.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net>]
* Re: [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
[not found] ` <12687093.1116061034131.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net>
@ 2005-05-15 18:49 ` Toon Moene
0 siblings, 0 replies; 33+ messages in thread
From: Toon Moene @ 2005-05-15 18:49 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
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/
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (24 preceding siblings ...)
[not found] ` <12687093.1116061034131.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net>
@ 2005-05-16 14:01 ` joel at oarcorp dot com
2005-05-16 14:05 ` corsepiu at gcc dot gnu dot org
2005-05-18 11:24 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
27 siblings, 0 replies; 33+ messages in thread
From: joel at oarcorp dot com @ 2005-05-16 14:01 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (25 preceding siblings ...)
2005-05-16 14:01 ` joel at oarcorp dot com
@ 2005-05-16 14:05 ` corsepiu at gcc dot gnu dot org
2005-05-18 11:24 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
27 siblings, 0 replies; 33+ messages in thread
From: corsepiu at gcc dot gnu dot org @ 2005-05-16 14:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
2005-04-25 8:21 [Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org
` (26 preceding siblings ...)
2005-05-16 14:05 ` corsepiu at gcc dot gnu dot org
@ 2005-05-18 11:24 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
27 siblings, 0 replies; 33+ messages in thread
From: Tobias dot Schlueter at physik dot uni-muenchen dot de @ 2005-05-18 11:24 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 33+ messages in thread