public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "fxcoudert at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/34230] Expressions of parameters evaluated with too high precision Date: Wed, 28 Nov 2007 19:24:00 -0000 [thread overview] Message-ID: <20071128192357.17833.qmail@sourceware.org> (raw) In-Reply-To: <bug-34230-13404@http.gcc.gnu.org/bugzilla/> ------- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-28 19:23 ------- (In reply to comment #7) > a) Do other compilers have an equivalent to -fno-range-check? Most compilers have a behaviour similar to -fno-range-check by default, only warning about range problems (Intel, Sun, g95 and Portland). On the example of this testcase, all report x and y as infinities. > b) The Fortran 95 standard is silent with respect to IEEE-754, > and the Fortran 2003 standard only considers IEEE-754 through > the explicit use of an intrinsic module. As I said: our current behaviour is standard-conforming, and -fno-range-check is asking to drop some of the standard constraints. What we do then is outside the scope of the standard, so we need to do something reasonable, and probably follow a principle of least surprise. > c) Are you suggesting that -ffpe-trap=invalid,overflow,zero should be > the default runtime behavior (to match gfortran's default > -frange-check behavior)? I am not, and don't see where I would imply such a thing. Trapping is widely different: it means throwing a FPE signal on certain floating-point exceptions. > If you want to be pedantic, this code is invalid > real, parameter :: y = exp(log(huge(y))+20) I do agree. That's what -fno-range-check is about: compile invalid code in cases where the community is not expecting bugs. In the end, I hope we win and noone writes invalid code. For now... well, lots of people and existing codes rely on such practice. > unless you're claiming +Inf is in the range of values representable by > a real No, I'm not. That would be stretching a bit far! > If +Inf is a representable value, you need to go fix the IO subsystem > to read +Inf (and NaN). Well, I happen to think that this would be a nice thing to do at some point. That's an extension to the standard, of course, but that would be, IMHO, a interesting one. > You'll also need to fix modules to properly handle +Inf and NaN. I wasn't aware of that one, but it is understandable. I think that it would indeed be nice to change that behaviour. To sum up my point of view: -fno-range-check is about accepting code which is, strictly speaking, invalid. It is thus an extension and we should be guided by a) what other compilers do, b) consistency, c) least surprise. Moreover, I don't think changing that behaviour would hurt maintainability much (but I might be wrong; we'll know when someone starts working on it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34230
next prev parent reply other threads:[~2007-11-28 19:24 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-11-25 21:44 [Bug fortran/34230] New: " burnus at gcc dot gnu dot org 2007-11-26 0:12 ` [Bug fortran/34230] " kargl at gcc dot gnu dot org 2007-11-27 21:57 ` terry at chem dot gu dot se 2007-11-27 22:45 ` kargl at gcc dot gnu dot org 2007-11-27 22:57 ` terry at chem dot gu dot se 2007-11-28 0:06 ` kargl at gcc dot gnu dot org 2007-11-28 18:03 ` fxcoudert at gcc dot gnu dot org 2007-11-28 19:06 ` kargl at gcc dot gnu dot org 2007-11-28 19:24 ` fxcoudert at gcc dot gnu dot org [this message] 2007-11-28 19:35 ` burnus at gcc dot gnu dot org 2007-11-28 20:08 ` sgk at troutmask dot apl dot washington dot edu 2007-11-30 4:11 ` jvdelisle at gcc dot gnu dot org 2007-11-30 4:18 ` jvdelisle at gcc dot gnu dot org 2007-12-02 21:02 ` jvdelisle 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=20071128192357.17833.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: linkBe 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).