[Bug c++/97790] New: constexpr evaluation reports false positive memory leak

[Bug c++/97790] New: constexpr evaluation reports false positive memory leak

[ldalessandro at gmail dot com]

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

            Bug ID: 97790
           Summary: constexpr evaluation reports false positive memory
                    leak
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

The constexpr evaluator seems to lose track of dynamic allocations in some
contexts, resulting in false-positive leaks and rejected valid code. 

This particular example uses an immediately invoked function expression
referencing an NTTP, which seems like a corner case but is actually extremely
common in two-pass constexpr algorithms (i.e., compute constexpr size of
result, then compute result to return).

https://godbolt.org/z/Tnn6xh

```
struct vector {
    int *data;
    int n;
    constexpr vector() : data(new int[1]{}), n(1) {}
    constexpr ~vector() { delete [] data; }
};

struct Foo {
    constexpr auto foo() const {
        return vector();
    }
};

template <auto& f>
constexpr static auto bar() {
    [] { return f.foo().n; }();
    return true;
}

constexpr Foo foo;
constexpr auto dd = bar<foo>();
```

[Bug c++/97790] constexpr evaluation reports false positive memory leak

[ldalessandro at gmail dot com]

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

--- Comment #1 from Luke Dalessandro <ldalessandro at gmail dot com> ---
It is possible to workaround this bug by creating a symbol for the offending
allocation in the IILE. 

https://godbolt.org/z/jeoEra


```
struct vector {
    int *data;
    int n;
    constexpr vector() : data(new int[1]{}), n(1) {}
    constexpr ~vector() { delete [] data; }
};

struct Foo {
    constexpr auto foo() const {
        return vector();
    }
};

template <auto& f>
constexpr static auto bar() {
    [] { 
        auto temp = f.foo(); // <-- **** GIVE THIS A NAME
        return temp.n; 
    }();
    return true;
}

constexpr Foo foo;
constexpr auto dd = bar<foo>();
```

[Bug c++/97790] constexpr evaluation reports false positive memory leak

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The lambda, or templates aren't needed for that.
struct S
{
  int *d;
  int n;
  constexpr S () : d(new int[1]{}), n(1) {}
  constexpr ~S () { delete [] d; }
};

constexpr S
foo ()
{
  return S ();
}

constexpr int
bar ()
{
  return foo ().n;
}

constexpr int
baz ()
{
  return S ().n;
}

constexpr int a = baz ();
constexpr int b = bar ();

[Bug c++/97790] constexpr evaluation reports false positive memory leak

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2020-11-11
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 49546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49546&action=edit
gcc11-pr97790.patch

Untested fix.

[Bug c++/97790] constexpr evaluation reports false positive memory leak

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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:fc531c2ed3ce456efca946e995544b216b3c16df

commit r11-4936-gfc531c2ed3ce456efca946e995544b216b3c16df
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Nov 12 10:46:04 2020 +0100

    c++: Fix up constexpr CLEANUP_POINT_EXPR and TRY_FINALLY_EXPR handling
[PR97790]

    As the testcase shows, CLEANUP_POINT_EXPR (and I think TRY_FINALLY_EXPR
too)
    suffer from the same problem that I was trying to fix in
    r10-3597-g1006c9d4395a939820df76f37c7b085a4a1a003f
    for CLEANUP_STMT, namely that if in the middle of the body expression of
    those stmts is e.g. return stmt, goto, break or continue (something that
    changes *jump_target and makes it start skipping stmts), we then skip the
    cleanups too, which is not appropriate - the cleanups were either queued up
    during the non-skipping execution of the body (for CLEANUP_POINT_EXPR), or
    for TRY_FINALLY_EXPR are relevant already after entering the body block.

    > Would it make sense to always use a NULL jump_target when evaluating
    > cleanups?

    I was afraid of that, especially for TRY_FINALLY_EXPR, but it seems that
    during constexpr evaluation the cleanups will most often be just very
simple
    destructor calls (or calls to cleanup attribute functions).
    Furthermore, for neither of these 3 tree codes we'll reach that code if
    jump_target && *jump_target initially (there is a return NULL_TREE much
    earlier for those except for trees that could embed labels etc. in it and
    clearly these 3 don't count in that).

    2020-11-12  Jakub Jelinek  <jakub@redhat.com>

            PR c++/97790
            * constexpr.c (cxx_eval_constant_expression) <case
CLEANUP_POINT_EXPR,
            case TRY_FINALLY_EXPR, case CLEANUP_STMT>: Don't pass jump_target
to
            cxx_eval_constant_expression when evaluating the cleanups.

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

[Bug c++/97790] constexpr evaluation reports false positive memory leak

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 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:d183dd5ca42bbfc1f840c59ffe2e42fbd6860707

commit r10-9012-gd183dd5ca42bbfc1f840c59ffe2e42fbd6860707
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Nov 12 10:46:04 2020 +0100

    c++: Fix up constexpr CLEANUP_POINT_EXPR and TRY_FINALLY_EXPR handling
[PR97790]

    As the testcase shows, CLEANUP_POINT_EXPR (and I think TRY_FINALLY_EXPR
too)
    suffer from the same problem that I was trying to fix in
    r10-3597-g1006c9d4395a939820df76f37c7b085a4a1a003f
    for CLEANUP_STMT, namely that if in the middle of the body expression of
    those stmts is e.g. return stmt, goto, break or continue (something that
    changes *jump_target and makes it start skipping stmts), we then skip the
    cleanups too, which is not appropriate - the cleanups were either queued up
    during the non-skipping execution of the body (for CLEANUP_POINT_EXPR), or
    for TRY_FINALLY_EXPR are relevant already after entering the body block.

    > Would it make sense to always use a NULL jump_target when evaluating
    > cleanups?

    I was afraid of that, especially for TRY_FINALLY_EXPR, but it seems that
    during constexpr evaluation the cleanups will most often be just very
simple
    destructor calls (or calls to cleanup attribute functions).
    Furthermore, for neither of these 3 tree codes we'll reach that code if
    jump_target && *jump_target initially (there is a return NULL_TREE much
    earlier for those except for trees that could embed labels etc. in it and
    clearly these 3 don't count in that).

    2020-11-12  Jakub Jelinek  <jakub@redhat.com>

            PR c++/97790
            * constexpr.c (cxx_eval_constant_expression) <case
CLEANUP_POINT_EXPR,
            case TRY_FINALLY_EXPR, case CLEANUP_STMT>: Don't pass jump_target
to
            cxx_eval_constant_expression when evaluating the cleanups.

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

    (cherry picked from commit fc531c2ed3ce456efca946e995544b216b3c16df)

[Bug c++/97790] constexpr evaluation reports false positive memory leak

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.3/11.