[Bug c++/102753] New: ICE on invalid use of pointer to a consteval member function

[Bug c++/102753] New: ICE on invalid use of pointer to a consteval member function

[aaron at aaronballman dot com]

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

            Bug ID: 102753
           Summary: ICE on invalid use of pointer to a consteval member
                    function
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aaron at aaronballman dot com
  Target Milestone: ---

The following code crashes GCC instead of giving an error:

struct test {
  consteval int f() const { return 12; }
};

constexpr test t;
int main() {
  (t.*&test::f)();
}

Note that the call to the PMF is not in a constant evaluated context.

https://godbolt.org/z/beWhE9qMv

[Bug c++/102753] ICE in cp_genericize_r on invalid use of pointer to a consteval member function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-10-14

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Clang gives:
<source>:7:8: error: cannot take address of consteval function 'f' outside of
an immediate invocation
  (t.*&test::f)();
       ^
<source>:2:17: note: declared here
  consteval int f() const { return 12; }
                ^

ICC accepts the code.
MSVC gives:
<source>(7): error C7596: 'test::f': cannot take address of immediate function
outside of an immediate invocation


Confirmed.

[Bug c++/102753] ICE in cp_genericize_r on invalid use of pointer to a consteval member function

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
                 CC|                            |jakub at gcc dot gnu.org

[Bug c++/102753] ICE in cp_genericize_r on invalid use of pointer to a consteval member function

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51612
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51612&action=edit
gcc12-pr102753.patch

Untested fix.

[Bug c++/102753] ICE in cp_genericize_r on invalid use of pointer to a consteval member function

[cvs-commit at gcc dot gnu.org]

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

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

commit r12-4730-g4b2fda8bea3fdcc9421726e5a21e537f745cad0b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Oct 27 09:03:28 2021 +0200

    c++: Diagnose taking address of an immediate member function [PR102753]

    The consteval20.C testcase ICEs, because while we have in
cp_build_addr_expr_1
    diagnostics for taking address of an immediate function (and as an
exception
    deal with build_address from immediate invocation), I forgot to diagnose
    taking address of a member function which is done in a different place.
    I hope (s.*&S::foo) () is not an immediate invocation like
    (*&foo) () is not, so this patch just diagnoses taking address of a member
    function when not in immediate context.

    On Mon, Oct 18, 2021 at 12:42:00PM -0400, Jason Merrill wrote:
    > > --- gcc/cp/typeck.c.jj      2021-10-05 09:53:55.382734051 +0200
    > > +++ gcc/cp/typeck.c 2021-10-15 19:28:38.034213437 +0200
    > > @@ -6773,9 +6773,21 @@ cp_build_addr_expr_1 (tree arg, bool str
    > >         return error_mark_node;
    > >       }
    > > +   if (TREE_CODE (t) == FUNCTION_DECL
    > > +       && DECL_IMMEDIATE_FUNCTION_P (t)
    > > +       && cp_unevaluated_operand == 0
    > > +       && (current_function_decl == NULL_TREE
    > > +           || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl)))
    >
    > This doesn't cover some of the other cases of immediate context; we
should
    > probably factor most of immediate_invocation_p out into a function called
    > something like in_immediate_context and use it here, and in several other
    > places as well.

    You're right, I've done that for the two spots in cp_build_addr_expr_1
    and added testsuite coverage for where it changed behavior.
    While doing that I've discovered further issues.

    One is that we weren't diagnosing PMFs referring to immediate methods
    returned from immediate functions (either directly or embedded in
    aggregates).  I'm not sure if it can only appear as PTRMEM_CST which
    I've handled (cp_walk_subtree only walks the type and not the
    PTRMEM_CST_MEMBER) or something else.

    Another issue is that while default arg in immediate function
    containing &immediate_fn works properly, if it is immediate_fn
    instead, we were incorrectly rejecting it.
    I've handled this in build_over_call, though with this usage
    in_consteval_if_p is slightly misnamed, it stands for in consteval
    if or some other reason why we are currently in immediate function context.
    Though, that flag alone can't be all the reasons for being in immediate
    function contexts, as I've tried the other reasons can't be handled in such
    a bool and need to be tested too.

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

            PR c++/102753
            * cp-tree.h (saved_scope): Document that consteval_if_p member
            is also set while processing immediate invocation.
            (in_immediate_context): Declare.
            * call.c (in_immediate_context): New function.
            (immediate_invocation_p): Use it.
            (struct in_consteval_if_p_temp_override): New class.
            (build_over_call): Temporarily set in_consteval_if_p for processing
            immediate invocation arguments.
            * typeck.c (cp_build_addr_expr_1): Diagnose taking address of
            an immediate method.  Use t instead of TREE_OPERAND (arg, 1).
            Use in_immediate_context function.
            * constexpr.c (find_immediate_fndecl): Handle PTRMEM_CST
            which refers to immediate function decl.

            * g++.dg/cpp2a/consteval13.C: Don't expect errors.
            * g++.dg/cpp2a/consteval20.C: New test.
            * g++.dg/cpp2a/consteval21.C: New test.
            * g++.dg/cpp2a/consteval22.C: New test.
            * g++.dg/cpp2a/consteval23.C: New test.
            * g++.dg/cpp23/consteval-if11.C: New test.

[Bug c++/102753] ICE in cp_genericize_r on invalid use of pointer to a consteval member function

[cvs-commit at gcc dot gnu.org]

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

--- 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:7473b8a90490e1dcd8fd5f7a92307d79fd2a5f8e

commit r12-4731-g7473b8a90490e1dcd8fd5f7a92307d79fd2a5f8e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Oct 27 09:08:19 2021 +0200

    c++: Reject addresses of immediate functions in constexpr vars inside of
immediate functions or consteval if [PR102753]

    Another thing that wasn't in the previous patch, but I'm wondering whether
we don't
    handle it incorrectly.  constexpr.c has:
      /* Check that immediate invocation does not return an expression
referencing
         any immediate function decls.  They need to be allowed while parsing
         immediate functions, but can't leak outside of them.  */
      if (is_consteval
          && t != r
          && (current_function_decl == NULL_TREE
              || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl)))
    as condition for the discovery of embedded immediate FUNCTION_DECLs
    (or now PTRMEM_CSTs).  If I remove the && (current... ..._decl))
    then g++.dg/cpp2a/consteval7.C's
    struct S { int b; int (*c) (); };
    consteval S baz () { return { 5, foo }; }
    consteval int qux () { S s = baz (); return s.b + s.c (); }
    consteval int quux () { constexpr S s = baz (); return s.b + s.c (); }
    quux line fails, but based on
    http://eel.is/c++draft/expr.const#11
    I wonder if it shouldn't fail (clang++ -std=c++20 rejects it),
    and be only accepted without the constexpr keyword before S s.
    Also wonder about e.g.
    consteval int foo () { return 42; }

    consteval int
    bar ()
    {
      auto fn1 = foo;  // This must be ok
      constexpr auto fn2 = foo; // Isn't this an error?
      return fn1 () + fn2 ();
    }

    constexpr int
    baz ()
    {
      if consteval {
        auto fn1 = foo; // This must be ok
        constexpr auto fn2 = foo; // Isn't this an error?
        return fn1 () + fn2 ();
      }
      return 0;
    }

    auto a = bar ();

    static_assert (bar () == 84);
    static_assert (baz () == 84);
    (again, clang++ -std=c++20 rejects the fn2 = foo; case,
    but doesn't implement consteval if, so can't test the other one).
    For taking address of an immediate function or method if it is taken
    outside of immediate function context we already have diagnostics
    about it, but shouldn't the immediate FUNCTION_DECL discovery in
    cxx_eval_outermost_constant_expression be instead guarded with something
    like
      if (is_consteval || in_immediate_context ())
    and be done regardless of whether t != r?

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

            PR c++/102753
            * constexpr.c (cxx_eval_outermost_constant_expr): Perform
            find_immediate_fndecl discovery if is_consteval or
            in_immediate_context () rather than if is_consteval, t != r
            and not in immediate function's body.

            * g++.dg/cpp2a/consteval7.C: Expect diagnostics on quux.
            * g++.dg/cpp2a/consteval24.C: New test.
            * g++.dg/cpp23/consteval-if12.C: New test.

[Bug c++/102753] ICE in cp_genericize_r on invalid use of pointer to a consteval member function

[cvs-commit at gcc dot gnu.org]

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

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

commit r12-5537-g8dedf065aff22b09bd4e48e1be0b77c58d297100
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Nov 26 10:11:13 2021 +0100

    c++: Fix up taking address of an immediate function diagnostics [PR102753]

    On Wed, Oct 20, 2021 at 07:16:44PM -0400, Jason Merrill wrote:
    > or an unevaluated operand, or a subexpression of an immediate invocation.
    >
    > Hmm...that suggests that in consteval23.C, bar(foo) should also be OK,

    The following patch handles that by removing the diagnostics about taking
    address of immediate function from cp_build_addr_expr_1, and instead
diagnoses
    it in cp_fold_r.  To do that with proper locations, the patch attempts to
    ensure that ADDR_EXPRs of immediate functions get EXPR_LOCATION set and
    adds a PTRMEM_CST_LOCATION for PTRMEM_CSTs.  Also, evaluation of
    std::source_location::current() is moved from genericization to cp_fold.

    2021-11-26  Jakub Jelinek  <jakub@redhat.com>

            PR c++/102753
            * cp-tree.h (struct ptrmem_cst): Add locus member.
            (PTRMEM_CST_LOCATION): Define.
            * tree.c (make_ptrmem_cst): Set PTRMEM_CST_LOCATION to
input_location.
            (cp_expr_location): Return PTRMEM_CST_LOCATION for PTRMEM_CST.
            * typeck.c (build_x_unary_op): Overwrite PTRMEM_CST_LOCATION for
            PTRMEM_CST instead of calling maybe_wrap_with_location.
            (cp_build_addr_expr_1): Don't diagnose taking address of
            immediate functions here.  Instead when taking their address make
            sure the returned ADDR_EXPR has EXPR_LOCATION set.
            (expand_ptrmemfunc_cst): Copy over PTRMEM_CST_LOCATION to
ADDR_EXPR's
            EXPR_LOCATION.
            (convert_for_assignment): Use cp_expr_loc_or_input_loc instead of
            EXPR_LOC_OR_LOC.
            * pt.c (tsubst_copy): Use build1_loc instead of build1.  Ensure
            ADDR_EXPR of immediate function has EXPR_LOCATION set.
            * cp-gimplify.c (cp_fold_r): Diagnose taking address of immediate
            functions here.  For consteval if don't walk THEN_CLAUSE.
            (cp_genericize_r): Move evaluation of calls to
            std::source_location::current from here to...
            (cp_fold): ... here.  Don't assert calls to immediate functions
must
            be source_location_current_p, instead only constant evaluate
            calls to source_location_current_p.

            * g++.dg/cpp2a/consteval20.C: Add some extra tests.
            * g++.dg/cpp2a/consteval23.C: Likewise.
            * g++.dg/cpp2a/consteval25.C: New test.
            * g++.dg/cpp2a/srcloc20.C: New test.