Bug 88335 - Implement P1073R3, C++20 immediate functions (consteval).
Summary: Implement P1073R3, C++20 immediate functions (consteval).
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 9.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 88323
  Show dependency treegraph
 
Reported: 2018-12-03 19:14 UTC by emsr
Modified: 2019-05-29 13:05 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2019-05-20 00:00:00


Attachments
gcc10-pr88335.patch (4.55 KB, patch)
2019-05-20 18:43 UTC, Jakub Jelinek
Details | Diff
gcc10-pr88335-wip.patch (7.46 KB, patch)
2019-05-21 12:20 UTC, Jakub Jelinek
Details | Diff
gcc10-pr88335-wip.patch (8.53 KB, patch)
2019-05-29 12:58 UTC, Jakub Jelinek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description emsr 2018-12-03 19:14:05 UTC

    
Comment 1 Jakub Jelinek 2019-05-20 18:43:18 UTC
Created attachment 46388 [details]
gcc10-pr88335.patch

Untested WIP patch.  Need to decide now from where exactly to call the immediate functions when not in immediate function contexts, shall that be done say from build_call_a/build_over_call once the expression is built and if nothing in the expression is dependent, or shall it be done say only from cp_fold?  The latter seems better conceptually (that we don't fold stuff too early), but might need to handle it also in various unevaluated codepaths.
Also, I guess if during !ctx->manifestly_const_eval constexpr evaluation we encounter immediate function call, we need to evaluate the call separately in a manifestly_const_eval mode and only then return back to the normal constexpr evaluation.
Some work will need to be done to make sure we don't hand over immediate functions to the middle-end, another question is what to do about virtual immediate functions, for the constexpr evaluations we want to see them in whatever data structures we have for virtual tables, but what we later hand over to the middle-end and emit should not include those, what shall we do with
classes that don't have any virtual members other than immediate functions, etc.
Comment 2 Jakub Jelinek 2019-05-20 18:44:03 UTC
Jason, thoughts on this?
Comment 3 Jakub Jelinek 2019-05-21 12:20:11 UTC
Created attachment 46390 [details]
gcc10-pr88335-wip.patch

Updated patch.  This one tries to evaluate immediate function calls immediately in build_over_call, adds some testsuite coverage etc.
What still doesn't work is:
1) consteval constructors, I think evaluating those in build_over_call is too early, we need a TARGET_EXPR for them or something similar that supplies to the constexpr evaluation the object that is being initialized; so, where should we do that and should we do that that way only for ctors, or everything?
2) the example added to the end of [expr.const] doesn't work - we have in cxx_eval_outermost_constant_expr:
  if (VOID_TYPE_P (type))
    return t;
early exit.  Is that something that is correct for anything?  I mean, aren't we supposed to evaluate the constexpr (and consteval) functions anyway?
constexpr void foo (bool x) { if (x) throw 1; }
constexpr int a = (foo (false), 1);
constexpr int b = (foo (true), 2);
is handled correctly though, because in that case the void type expressions are the outermost ones.  Perhaps we should do this early exit only if the expression isn't a call to an immediate function?
3) consteval virtual members not handled at all, and I'm afraid that is out of my area of expertise
Comment 4 Jakub Jelinek 2019-05-21 13:12:52 UTC
Not working on this anymore.
Comment 5 Jakub Jelinek 2019-05-29 12:58:21 UTC
Created attachment 46429 [details]
gcc10-pr88335-wip.patch

Slightly updated patch.
Comment 6 Jakub Jelinek 2019-05-29 13:05:24 UTC
The above patch:
1) adds sorry_at for virtual consteval, that is quite a lot of work
2) still doesn't handle ctors properly (perhaps sorry_at too)?
3) fixes the testcase from the paper with decltype containing call to void returning consteval fn
4) adds diagnostics for immediate invocation returning address of some immediate function
Unfortunately 4) breaks consteval2.C testcase, my reading of the spec is we should treat default arguments of immediate functions as in immediate function context and not evaluate immediately, but current_function_decl at that point doesn't indicate we are in immediate function context, and I guess we don't even have such a decl.  Jason, any thoughts on that?