[Bug c++/99031] New: Comparing pointers to heap-allocated memory is not a constant expression

[Bug c++/99031] New: Comparing pointers to heap-allocated memory is not a constant expression

[david at doublewise dot net]

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

            Bug ID: 99031
           Summary: Comparing pointers to heap-allocated memory is not a
                    constant expression
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david at doublewise dot net
  Target Milestone: ---

The following valid translation unit

```
constexpr bool f() {
        auto a = new int;
        auto b = new int;
        if (a == b) {
        }
        delete b;
        delete a;
        return true;
}

static_assert(f());
```

is rejected with

```
<source>:11:16: error: non-constant condition for static assertion
   11 | static_assert(f());
      |               ~^~
<source>:11:16:   in 'constexpr' expansion of 'f()'
<source>:4:15: error: '(((int*)(& heap )) == ((int*)(& heap )))' is not a
constant expression
    4 |         if (a == b) {
      |             ~~^~~~
Compiler returned: 1
```

See it live: https://godbolt.org/z/of45no

[Bug c++/99031] Comparing pointers to heap-allocated memory is not a constant expression

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:a8db7887dfbf502b7e60d64bfeebd0de592d2d45

commit r11-7176-ga8db7887dfbf502b7e60d64bfeebd0de592d2d45
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Feb 10 19:31:15 2021 +0100

    c++: Consider addresses of heap artificial vars always non-NULL [PR98988,
PR99031]

    With -fno-delete-null-pointer-checks which is e.g. implied by
    -fsanitize=undefined or default on some embedded targets, the middle-end
    folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as
one
    of them could have address 0.  Still, I think malloc/operator new (at least
    the nonthrowing) relies on NULL returns meaning allocation failure rather
    than success.  Furthermore, the artificial VAR_DECLs we create for
    constexpr new never actually live in the address space of the program,
    so we can pretend they will never be NULL too.

    > I'm surprised that nonzero_address has such a limited set of things it
will
    > actually believe have non-zero addresses with
    > -fno-delete-null-pointer-checks.  But it seems that we should be able to
    > arrange to satisfy
    >
    > >   if (definition && !DECL_EXTERNAL (decl)
    >
    > since these "variables" are indeed defined within the current translation
    > unit.

    Doing that seems to work and as added benefit it fixes another PR that has
    been filed recently.  I need to create the varpool node explicitly and call
    a method that sets the definition member in there, but I can also
unregister
    those varpool nodes at the end of constexpr processing, as the processing
    ensured they don't leak outside of the processing.

    2021-02-10  Jakub Jelinek  <jakub@redhat.com>

            PR c++/98988
            PR c++/99031
            * constexpr.c: Include cgraph.h.
            (cxx_eval_call_expression): Call varpool_node::finalize_decl on
            heap artificial vars.
            (cxx_eval_outermost_constant_expr): Remove varpool nodes for
            heap artificial vars.

            * g++.dg/cpp2a/constexpr-new16.C: New test.
            * g++.dg/cpp2a/constexpr-new17.C: New test.

[Bug c++/99031] Comparing pointers to heap-allocated memory is not a constant expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug c++/99031] Comparing pointers to heap-allocated memory is not a constant expression

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:4b47af4346ad0e8a428c09791111f6f61feb6579

commit r10-9466-g4b47af4346ad0e8a428c09791111f6f61feb6579
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Feb 10 19:31:15 2021 +0100

    c++: Consider addresses of heap artificial vars always non-NULL [PR98988,
PR99031]

    With -fno-delete-null-pointer-checks which is e.g. implied by
    -fsanitize=undefined or default on some embedded targets, the middle-end
    folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as
one
    of them could have address 0.  Still, I think malloc/operator new (at least
    the nonthrowing) relies on NULL returns meaning allocation failure rather
    than success.  Furthermore, the artificial VAR_DECLs we create for
    constexpr new never actually live in the address space of the program,
    so we can pretend they will never be NULL too.

    > I'm surprised that nonzero_address has such a limited set of things it
will
    > actually believe have non-zero addresses with
    > -fno-delete-null-pointer-checks.  But it seems that we should be able to
    > arrange to satisfy
    >
    > >   if (definition && !DECL_EXTERNAL (decl)
    >
    > since these "variables" are indeed defined within the current translation
    > unit.

    Doing that seems to work and as added benefit it fixes another PR that has
    been filed recently.  I need to create the varpool node explicitly and call
    a method that sets the definition member in there, but I can also
unregister
    those varpool nodes at the end of constexpr processing, as the processing
    ensured they don't leak outside of the processing.

    2021-02-10  Jakub Jelinek  <jakub@redhat.com>

            PR c++/98988
            PR c++/99031
            * constexpr.c: Include cgraph.h.
            (cxx_eval_call_expression): Call varpool_node::finalize_decl on
            heap artificial vars.
            (cxx_eval_outermost_constant_expr): Remove varpool nodes for
            heap artificial vars.

            * g++.dg/cpp2a/constexpr-new16.C: New test.
            * g++.dg/cpp2a/constexpr-new17.C: New test.

    (cherry picked from commit a8db7887dfbf502b7e60d64bfeebd0de592d2d45)