[Bug c++/101443] [9/10/11 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1519

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:2f49122aec76fdd40a7157f66df9c058d635efe6

commit r11-8772-g2f49122aec76fdd40a7157f66df9c058d635efe6
Author: Jakub Jelinek <jakub@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  <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)