diff options
author | Jakub Jelinek <jakub@redhat.com> | 2023-03-02 09:27:40 +0100 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2023-03-02 09:27:40 +0100 |
commit | cc88366a80e35b3e53141f49d3071010ff3c2ef8 (patch) | |
tree | 6bddb8b53d18f50e77dd6b050dfe0a2d0dcf1204 /gcc/fold-const.cc | |
parent | f0ef740d54f47ff614eb02e13e8f4cb11dfbb140 (diff) | |
download | gcc-cc88366a80e35b3e53141f49d3071010ff3c2ef8.zip gcc-cc88366a80e35b3e53141f49d3071010ff3c2ef8.tar.gz gcc-cc88366a80e35b3e53141f49d3071010ff3c2ef8.tar.bz2 |
fold-const: Ignore padding bits in native_interpret_expr REAL_CST reverse verification [PR108934]
In the following testcase we try to std::bit_cast a (pair of) integral
value(s) which has some non-zero bits in the place of x86 long double
(for 64-bit 16 byte type with 10 bytes actually loaded/stored by hw,
for 32-bit 12 byte) and starting with my PR104522 change we reject that
as native_interpret_expr fails on it. The PR104522 change extends what
has been done before for MODE_COMPOSITE_P (but those don't have any padding
bits) to all floating point types, because e.g. the exact x86 long double
has various bit combinations we don't support, like
pseudo-(denormals,infinities,NaNs) or unnormals. The HW handles some of
those as exceptional cases and others similarly to the non-pseudo ones.
But for the padding bits it actually doesn't load/store those bits at all,
it loads/stores 10 bytes. So, I think we should exempt the padding bits
from the reverse comparison (the native_encode_expr bits for the padding
will be all zeros), which the following patch does. For bit_cast it is
similar to e.g. ignoring padding bits if the destination is a structure
which has padding bits in there.
The change changed auto-init-4.c to how it has been behaving before the
PR105259 change, where some more VCEs can be now done.
2023-03-02 Jakub Jelinek <jakub@redhat.com>
PR c++/108934
* fold-const.cc (native_interpret_expr) <case REAL_CST>: Before memcmp
comparison copy the bytes from ptr to a temporary buffer and clearing
padding bits in there.
* gcc.target/i386/auto-init-4.c: Revert PR105259 change.
* g++.target/i386/pr108934.C: New test.
Diffstat (limited to 'gcc/fold-const.cc')
-rw-r--r-- | gcc/fold-const.cc | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc index 9aaea71..99882ef 100644 --- a/gcc/fold-const.cc +++ b/gcc/fold-const.cc @@ -8873,11 +8873,13 @@ native_interpret_expr (tree type, const unsigned char *ptr, int len) valid values that GCC can't really represent accurately. See PR95450. Even for other modes, e.g. x86 XFmode can have some bit combinationations which GCC doesn't preserve. */ - unsigned char buf[24]; + unsigned char buf[24 * 2]; scalar_float_mode mode = SCALAR_FLOAT_TYPE_MODE (type); int total_bytes = GET_MODE_SIZE (mode); + memcpy (buf + 24, ptr, total_bytes); + clear_type_padding_in_mask (type, buf + 24); if (native_encode_expr (ret, buf, total_bytes, 0) != total_bytes - || memcmp (ptr, buf, total_bytes) != 0) + || memcmp (buf + 24, buf, total_bytes) != 0) return NULL_TREE; return ret; } |