diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2026-01-30 11:40:17 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@gcc.gnu.org> | 2026-01-30 11:40:17 +0100 |
| commit | cffe5fd7c98babd85acf86f3e7f8d02b04416ec2 (patch) | |
| tree | 3896a704f9d2cd2e5f1a4c986eb0acca11fa1c41 /libjava/gnu/java | |
| parent | 919b6fa6adcc102f95b17c13e8bdc26fd4ec1394 (diff) | |
| download | gcc-cffe5fd7c98babd85acf86f3e7f8d02b04416ec2.zip gcc-cffe5fd7c98babd85acf86f3e7f8d02b04416ec2.tar.gz gcc-cffe5fd7c98babd85acf86f3e7f8d02b04416ec2.tar.bz2 | |
fold-const: Fix implicit cast to nullptr_t typedef [PR123790]
The following testcase is incorrectly rejected, because since r15-6744
it adds build_nop to preserve the exact typedef type and
cxx_eval_constant_expression can't fold NOP_EXPR from integer_zerop of one
NULLPTR_TYPE to another NULLPTR_TYPE, while cxx_eval_constant_expression
relies on fold to do such folding.
I see 3 options to fix that, one is deal with this in the r15-6744 spot
and special case NULLPTR_TYPE there and build_zero_cst instead of build_nop
(with similar condition like in the patch below), another possibility is
special case this in cxx_eval_constant_expression, and
another one (done in this patch) is to handle this in fold-const.cc -
fold_convert_loc and also in fold_convert_const.
2026-01-30 Jakub Jelinek <jakub@redhat.com>
PR c++/123790
* fold-const.cc (fold_convert_const): Handle conversion of
integer_zerop to NULLPTR_TYPE.
(fold_convert_loc): Likewise.
* g++.dg/cpp0x/nullptr47.C: New test.
Diffstat (limited to 'libjava/gnu/java')
0 files changed, 0 insertions, 0 deletions
