[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287 --- Comment #8 from Iain Sandoe --- so the ICE should be fixed for gcc-12, and given tracking the issues in PR 105382 this could be closed now, I'd think.
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287 --- Comment #7 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:15a176a833f23e64ad38690a678bf938227ce46f commit r12-8308-g15a176a833f23e64ad38690a678bf938227ce46f Author: Iain Sandoe Date: Sun Apr 17 20:58:28 2022 +0100 c++, coroutines: Make sure our temporaries are in a bind expr [PR105287] There are a few cases where we can generate a temporary that does not need to be added to the coroutine frame (i.e. these are genuinely ephemeral). The intent was that unnamed temporaries should not be 'promoted' to coroutine frame entries. However there was a thinko and these were not actually ever added to the bind expressions being generated for the expanded awaits. This meant that they were showing in the global namspace, leading to an empty DECL_CONTEXT and the ICE reported. Signed-off-by: Iain Sandoe PR c++/105287 gcc/cp/ChangeLog: * coroutines.cc (maybe_promote_temps): Ensure generated temporaries are added to the bind expr. (add_var_to_bind): Fix local var naming to use portable punctuation. (register_local_var_uses): Do not add synthetic names to unnamed temporaries. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr105287.C: New test.
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287 --- Comment #6 from Iain Sandoe --- (In reply to David Malcolm from comment #5) > Thanks. FWIW I've filed PR 105382 to track the various other issues I'm > seeing with -fanalyzer with coroutines (though given that we don't properly > support C++ yet, that's relatively low priority for me). Yeah, even given bug-free coroutines (heh) I think we would need to teach the analyser about the outlining and deferred destruction etc.
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287 --- Comment #5 from David Malcolm --- Thanks. FWIW I've filed PR 105382 to track the various other issues I'm seeing with -fanalyzer with coroutines (though given that we don't properly support C++ yet, that's relatively low priority for me).
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287 --- Comment #4 from Iain Sandoe --- candidate patch for the ICE (I am not sure if there's anything needed on the analyser side). https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593317.html
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287 --- Comment #3 from Iain Sandoe --- Initial analysis ... 1. The coroutines code is supposed to ensure that the local variables are given the context of the enclosing function (whether that is the ramp or the outlined actor). coroutines.cc: 2023 /* Re-write the variable's context to be in the actor func. */ 2024 DECL_CONTEXT (lvar) = lvd->context; So, one issue to resolve is why that is apparently not working for the temporary condition variable in question. 2. DECL_CONTEXT can validly be NULL_TREE (when the decl is in the global namespace) GCC internals: DECL_CONTEXT This macro returns the enclosing namespace. The DECL_CONTEXT for the global_namespace is NULL_TREE. Both things need to be addressed (even if fixing [1] will make the ICE go away for this code, there will surely be code that intentionally places vars in the global namespace). FWIW, I looked at the output of the analyser with my WIP branch (for which the ICE does not fire) - and TBH suspect that it will not be terribly useful until we can teach it about the outlining done for coroutines (the fact that some values persist, intentionally, beyond the closing brace of the initial call is going to be an interesting thing to figure out).
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287
--- Comment #2 from Iain Sandoe ---
(In reply to David Malcolm from comment #1)
> Confirmed; it's an assertion failing in
> ana::frame_region::get_region_for_local, due to a variable having NULL for
> its DECL_CONTEXT:
>
> (gdb) list
> 869 case SSA_NAME:
> 870 {
> 871 if (tree var = SSA_NAME_VAR (expr))
> 872 {
> 873 if (DECL_P (var))
> 874 gcc_assert (DECL_CONTEXT (var) == m_fun->decl);
> 875 }
>
> This is probably benign if assertions are disabled (perhaps the analyzer is
> being more fussy than the rest of the middle-end?)
>
> (gdb) call debug_tree(var)
> type type_6 QI
> size
> unit-size
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x7fffea665b28 precision:1 min max
>
> pointer_to_this >
> unsigned QI ../../src/gcc/testsuite/g++.dg/analyzer/pr105287.C:35:73
> size unit-size
> align:8 warn_if_not_align:0>
> (gdb) p var.decl_minimal.context
> $2 =
>
>
> The var_decl is "cond_var" created here in the C++ FE:
>
> #4 0x00b30ec2 in flatten_await_stmt (n=0x317b9b0,
> promoted=0x7fffcc40, temps_used=0x7fffcc70, replace_in= out>)
> at ../../src/gcc/cp/coroutines.cc:2792
> 2792tree cond_var = build_lang_decl (VAR_DECL, NULL_TREE,
> cond_type);
> (gdb) list
> 2787/* If the condition contains an await expression, then we
> need to
> 2788 set that first and use a separate var. */
> 2789if (cp_walk_tree (, find_any_await, , NULL))
> 2790 {
> 2791tree cond_type = TREE_TYPE (cond);
> 2792tree cond_var = build_lang_decl (VAR_DECL, NULL_TREE,
> cond_type);
> 2793DECL_ARTIFICIAL (cond_var) = true;
> 2794layout_decl (cond_var, 0);
> 2795gcc_checking_assert (!TYPE_NEEDS_CONSTRUCTING
> (cond_type));
> 2796cond = build2 (INIT_EXPR, cond_type, cond_var, cond);
> 2797var_nest_node *ins
> 2798 = new var_nest_node (cond_var, cond, n->prev, n);
> 2799COND_EXPR_COND (n->init) = cond_var;
> 2800flatten_await_stmt (ins, promoted, temps_used, NULL);
> 2801 }
>
> Iain: shouldn't the DECL_CONTEXT be being set on var_decls created here?
I'd expect so; does build_lang_decl() not add them to the current context? [I
didn't look at the code, and memory might be faulty there]. If it doesn't then
I need to take a pass through and add the appropriate one.
