diff options
author | Jakub Jelinek <jakub@redhat.com> | 2025-04-04 17:27:56 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@gcc.gnu.org> | 2025-04-04 17:30:32 +0200 |
commit | aa9d3f17ff359ecad729a9436adbbf644aab2426 (patch) | |
tree | 355e9f7296da97209861921c6dbf658029cd3c29 /libjava/classpath/lib/java | |
parent | 6e79fa4a25769b2facf519aaf04b2a757dd3c887 (diff) | |
download | gcc-aa9d3f17ff359ecad729a9436adbbf644aab2426.zip gcc-aa9d3f17ff359ecad729a9436adbbf644aab2426.tar.gz gcc-aa9d3f17ff359ecad729a9436adbbf644aab2426.tar.bz2 |
c++, libcpp: Allow some left shifts in the preprocessor [PR119391]
The libcpp left shift handling implements (partially) the C99-C23
wording where shifts are UB if shift count is negative, or too large,
or shifting left a negative value or shifting left non-negative value
results in something not representable in the result type (in the
preprocessor case that is intmax_t).
libcpp actually implements left shift by negative count as right shifts
by negation of the count and similarly right shifts by negative count
as left shifts by negation (not ok), sets overflow for too large shift
count (ok), doesn't check for negative values on left shift (not ok)
and checks correctly for the non-representable ones otherwise (ok).
Now, C++11 to C++17 has different behavior, whereas in C99-C23 1 << 63
in preprocessor is invalid, in C++11-17 it is valid, but 3 << 63 is
not. The wording is that left shift of negative value is UB (like in C)
and signed non-negative left shift is UB if the result isn't representable
in corresponding unsigned type (so uintmax_t for libcpp).
And then C++20 and newer says all left shifts are well defined with the
exception of bad shift counts.
In -fsanitize=undefined we handle these by
/* For signed x << y, in C99 and later, the following:
(unsigned) x >> (uprecm1 - y)
if non-zero, is undefined. */
and
/* For signed x << y, in C++11 to C++17, the following:
x < 0 || ((unsigned) x >> (uprecm1 - y))
if > 1, is undefined. */
Now, we are late in GCC 15 development, so I think making the preprocessor
more strict than it is now is undesirable, so will defer setting overflow
flag for the shifts by negative count, or shifts by negative value left.
The following patch just makes some previously incorrectly rejected or
warned cases valid for C++11-17 and even more for C++20 and later.
2025-04-04 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/119391
* expr.cc (num_lshift): Add pfile argument. Don't set num.overflow
for !num.unsignedp in C++20 or later unless n >= precision. For
C++11 to C++17 set it if orig >> (precision - 1 - n) as logical
shift results in value > 1.
(num_binary_op): Pass pfile to num_lshift.
(num_div_op): Likewise.
* g++.dg/cpp/pr119391.C: New test.
Diffstat (limited to 'libjava/classpath/lib/java')
0 files changed, 0 insertions, 0 deletions