public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "corsepiu at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
Date: Sat, 14 May 2005 08:14:00 -0000	[thread overview]
Message-ID: <20050514081448.24990.qmail@sourceware.org> (raw)
In-Reply-To: <20050425082043.21203.corsepiu@gcc.gnu.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


  parent reply	other threads:[~2005-05-14  8:14 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-25  8:21 [Bug fortran/21203] New: " 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
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
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
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
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
2005-05-14  7:08 ` pinskia at physics dot uc dot edu
2005-05-14  8:14 ` corsepiu at gcc dot gnu dot org [this message]
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
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
     [not found] ` <12687093.1116061034131.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net>
2005-05-15 18:49   ` Toon Moene
2005-05-15 18:49 ` toon at moene dot indiv dot nluug dot nl
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
     [not found] <bug-21203-9565@http.gcc.gnu.org/bugzilla/>
2006-02-12 18:47 ` tobi at gcc dot gnu dot org
2006-09-25  9:19 ` fxcoudert at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050514081448.24990.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).