https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-10 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:2adeae7ab5f7bd274f3dda58baa04710699e59be commit r10-10632-g2adeae7ab5f7bd274f3dda58baa04710699e59be Author: Jakub Jelinek <ja...@redhat.com> Date: Thu Jul 15 18:53:20 2021 +0200 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 <ja...@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)
