diff options
author | Aldy Hernandez <aldyh@redhat.com> | 2022-09-05 07:36:25 +0200 |
---|---|---|
committer | Aldy Hernandez <aldyh@redhat.com> | 2022-09-05 22:16:04 +0200 |
commit | 1de9aa45529a98a5760a21570b181b78dbd11b3c (patch) | |
tree | 0380a9734669fd24b4a268b0b4410948e8a8c65f /libcpp | |
parent | 810d9815249451f477d4cbc67b8e4a0819c37faa (diff) | |
download | gcc-1de9aa45529a98a5760a21570b181b78dbd11b3c.zip gcc-1de9aa45529a98a5760a21570b181b78dbd11b3c.tar.gz gcc-1de9aa45529a98a5760a21570b181b78dbd11b3c.tar.bz2 |
Fold __builtin_signbit to nonzero instead of 1.
After Joseph's comment wrt __builtin_signbit, I have been unable to
convince myself that arbitrarily folding __builtin_signbit () of a
negative number to 1 is correct.
For example, on the true side of x < -5.0 we know the sign bit is set,
but on the false side, we know nothing because X may be a NAN. I
don't want to put ourselves in a position where the same call to
__builtin_signbit can return two different things (1 or negative
whatever), so I'm going to return nonzero which is correct across the
board until someone can convince me otherwise.
Setting the range to nonzero still allows us to fold conditionals
checking __fold_builtin, while not actually propagating a 1. Zero
propagation still works.
That being said, I still think we should be folding
__builtin_signbit's of negative numbers to whatever the hardware
returns, instead of 1/0 like what the front ends do.
gcc/ChangeLog:
* gimple-range-fold.cc
(fold_using_range::range_of_builtin_int_call): Fold a set signbit
in __builtin_signbit to nonzero.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/vrp-float-signbit-2.c: New test.
Diffstat (limited to 'libcpp')
0 files changed, 0 insertions, 0 deletions