public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "kargl 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 00:06:00 -0000 [thread overview] Message-ID: <20071128000627.13313.qmail@sourceware.org> (raw) In-Reply-To: <bug-34230-13404@http.gcc.gnu.org/bugzilla/> ------- Comment #5 from kargl at gcc dot gnu dot org 2007-11-28 00:06 ------- (In reply to comment #4) > (In reply to comment #3) > > (Admittedly from the 4.2.2 manual): > 2.2 Options controlling Fortran dialect > -frange-check > Enable range checking on results of simplification of constant expressions > during compilation. For example, by default, GNU Fortran will give an overflow > error at compile time when simplifying a = EXP(1000). With -fno-range-check, no > error will be given and the variable a will be assigned the value +Infinity. The documentation is wrong. Fortunately, I didn't write it. I do commend you on actually trying to use the documentation. > Referring to compiler output agreeing with itself is not a particularly strong > argument. I wrote or reworked most of the constant folding done in gfortran. I think I may be able to speak with some authority as to what the constant folding is doing. Showing the compiler's internal state in comment #3 was only motivated by your comment #2, which appears to show that you don't understand my comment #1. > Surely it's reasonable for the programmer to assume that if y is +Inf, than > log(y) will be also. But, y is not +Inf. > (Though I can see this degenerating into a discussion about -ffloat-store.) This absolutely nothing to do with -ffloat-store. It has to do with misleading documentation. I'll submit a patch to fix that snafu. I suspect that the only legal, but non-portable, method that allows one to get an inf value in a variable is via TRANSFER(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34230
next prev parent reply other threads:[~2007-11-28 0:06 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 [this message] 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 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=20071128000627.13313.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).