public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Vincent Lefevre <vincent+gcc@vinc17.org>
To: gcc-help@gcc.gnu.org
Subject: Re: Compile-time floating-point expressions and subsequent detection of possible overflows etc -- during the compile-time stage.
Date: Wed, 02 Nov 2011 09:01:00 -0000	[thread overview]
Message-ID: <20111102090102.GA3523@xvii.vinc17.org> (raw)
In-Reply-To: <CAPpySAYbqZE+B-BqwW6ZY9rD9tZYG5Ru+tQ6HJOfPC13Tkonew@mail.gmail.com>

On 2011-11-02 15:31:42 +1100, leon zadorin wrote:
> Under certain conditions GCC is able to perform compile-time folding
> of floating point expressions. This is great.
> 
> Sometimes, however, the resulting (or indeed intermediate) expressions
> may evaluate to a non-finite value (e.g. NaN, Inf) -- at compile-time.
> 
> During a traditional run-time execution of floating point arithmetic
> there are various ways to detect the case of values going into
> something like an overflow (individual guarding of each
> possibly-violating expression via 'isfinite()'; or via reading the FPU
> status register, which hardware itself may flag appropriately; or via
> the 'fetestexcept' et al wrappers).
> 
> I was wondering if there was a way to ask GCC to optionally emit some
> kind of a diagnostic (e.g. a warning of some kind) when it does
> floating point calculations at compile-time and when such compile-time
> calculations yield in a non-finite number.

In ISO C99, I don't think the compiler is allowed to replace a
floating expression with an underflow or overflow by its result
at compile time. 6.6#4 of ISO C99 says: "Each constant expression
shall evaluate to a constant that is in the range of representable
values for its type." and an underflow or overflow means that the
result is not in the range of representable values, so that the
rules for constant expressions must not be applied.

Now, I don't know what C++ allows (in your case) and I haven't
tested how GCC behaves (there may be a bug...).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

  reply	other threads:[~2011-11-02  9:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-02  4:31 leon zadorin
2011-11-02  9:01 ` Vincent Lefevre [this message]
2011-11-02  9:37   ` Andrew Haley
2011-11-02 13:36     ` leon zadorin
2011-11-03 12:30       ` Vincent Lefevre
2011-11-03 14:28         ` leon zadorin
2011-11-03 15:12           ` Vincent Lefevre
2011-11-03 15:56             ` leon zadorin
2011-11-03 12:15     ` Vincent Lefevre

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=20111102090102.GA3523@xvii.vinc17.org \
    --to=vincent+gcc@vinc17.org \
    --cc=gcc-help@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).