public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] c++: Disable -frounding-math during manifestly constant evaluation [PR96862]
Date: Thu, 3 Sep 2020 17:03:42 +0200	[thread overview]
Message-ID: <20200903150342.GO18149@tucnak> (raw)
In-Reply-To: <ee6ddb5f-7515-5b35-3bcf-1a1f3f0eb0b0@redhat.com>

On Wed, Sep 02, 2020 at 04:55:14PM -0400, Jason Merrill via Gcc-patches wrote:
> C++ says that division by zero has undefined behavior, and that an
> expression with undefined behavior is not constant, so we shouldn't fold
> 1./0 to inf anyway.  The same is true of other trapping operations.  So
> clearing flag_signaling_nans, flag_trapping_math, and flag_trapv seems wrong
> for C++.  And folding_initializer seems to be used for the same sort of
> thing.

I indeed see:
"If during the evaluation of an expression, the result is not mathematically defined or not in the range of
representable values for its type, the behavior is undefined. [Note: Treatment of division by zero, forming a
remainder using a zero divisor, and all floating-point exceptions vary among machines, and is sometimes
adjustable by a library function. — end note]"

Now, for floating point exceptions, we have several of them.
I'd hope the inexact one shouldn't count, because otherwise we can't
evaluate at compile time pretty much nothing (but we actually seem to ignore
inexact during fold const except for rounding math).
The other exceptions are invalid, which is for the not mathematically
defined cases (0 / 0, inf - inf and the like), yes, they can be expressed as
NaNs, but I guess the above make it undefined.
Then there are overflows into infinities, should that count as not
representable?
Underflows are more like inexact I'd say.
So perhaps we should have a special flag that fold-const.c checks next to
flag_signalling_math and decide what is and is not undefined.

	Jakub


      parent reply	other threads:[~2020-09-03 15:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-01  7:49 Jakub Jelinek
2020-09-01 10:13 ` Marc Glisse
2020-09-02 20:55   ` Jason Merrill
2020-09-02 22:43     ` Marc Glisse
2020-09-03 18:25       ` Jason Merrill
2020-09-03 15:03     ` Jakub Jelinek [this message]

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=20200903150342.GO18149@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /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).