]> git.ipfire.org Git - thirdparty/gcc.git/commit
c++: Optimize away NULLPTR_TYPE comparisons [PR101443]
authorJakub Jelinek <jakub@redhat.com>
Thu, 15 Jul 2021 16:53:20 +0000 (18:53 +0200)
committerJakub Jelinek <jakub@redhat.com>
Tue, 10 May 2022 08:14:25 +0000 (10:14 +0200)
commit2adeae7ab5f7bd274f3dda58baa04710699e59be
treeacb4ad0d796208aa4adc08b8bd8fc57c3003fbc0
parent2c7087f46bb8c3f698cc475ece3786582bd34da0
c++: Optimize away NULLPTR_TYPE comparisons [PR101443]

Comparisons of NULLPTR_TYPE operands cause all kinds of problems in the
middle-end and in fold-const.c, various optimizations assume that if they
see e.g. a non-equality comparison with one of the operands being
INTEGER_CST and it is not INTEGRAL_TYPE_P (which has TYPE_{MIN,MAX}_VALUE),
they can build_int_cst (type, 1) to find a successor.

The following patch fixes it by making sure they don't appear in the IL,
optimize them away at cp_fold time as all can be folded.

Though, I've just noticed that clang++ rejects the non-equality comparisons
instead, foo () > 0 with
invalid operands to binary expression ('decltype(nullptr)' (aka 'nullptr_t') and 'int')
and foo () > nullptr with
invalid operands to binary expression ('decltype(nullptr)' (aka 'nullptr_t') and 'nullptr_t')

Shall we reject those too, in addition or instead of parts of this patch?
If so, wouldn't this patch be still useful for backports, I bet we don't
want to start reject it on the release branches when we used to accept it.

2021-07-15  Jakub Jelinek  <jakub@redhat.com>

PR c++/101443
* cp-gimplify.c (cp_fold): For comparisons with NULLPTR_TYPE
operands, fold them right away to true or false.

* g++.dg/cpp0x/nullptr46.C: New test.

(cherry picked from commit 7094a69bd62a14dfa311eaa2fea468f221c7c9f3)
gcc/cp/cp-gimplify.c
gcc/testsuite/g++.dg/cpp0x/nullptr46.C [new file with mode: 0644]