[Bug c++/98988] New: delete is not a constant expression with -fsanitize=undefined

[Bug c++/98988] New: delete is not a constant expression with -fsanitize=undefined

[david at doublewise dot net]

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

            Bug ID: 98988
           Summary: delete is not a constant expression with
                    -fsanitize=undefined
           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 ptr = new int();
        delete ptr;
        return true;
}

static_assert(f());
```

is incorrectly rejected when compiled with `-fsanitize=undefined`, complaining
about

```
<source>:7:16: error: non-constant condition for static assertion
    7 | static_assert(f());
      |               ~^~
<source>:7:16:   in 'constexpr' expansion of 'f()'
<source>:3:9: error: '(((int*)(& heap )) != 0)' is not a constant expression
    3 |         delete ptr;
      |         ^~~~~~~~~~
Compiler returned: 1
```

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

[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Some sanitizers imply -fno-delete-null-pointer-checks and this testcase fails
with  fno-delete-null-pointer-checks too - the &heap_magic_var_decl != NULL
comparison in that case which is done on delete is not folded into true.
Wonder if at least for the magic heap vars we shouldn't fold comparisons
against NULL, because those will never live in any memory and thus we can
pretend their address will never be 0.

[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 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++/98988] delete is not a constant expression with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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)