public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
Date: Sat, 16 Apr 2022 19:23:23 +0000	[thread overview]
Message-ID: <bug-105287-4-Hcie6SBcsw@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-105287-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
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).

  parent reply	other threads:[~2022-04-16 19:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-15 12:10 [Bug analyzer/105287] New: [12 Regression] ICE in get_region_for_local, at analyzer/region.cc:874 asolokha at gmx dot com
2022-04-15 14:59 ` [Bug analyzer/105287] " dmalcolm at gcc dot gnu.org
2022-04-15 15:19 ` [Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var iains at gcc dot gnu.org
2022-04-16 19:23 ` iains at gcc dot gnu.org [this message]
2022-04-18 14:06 ` iains at gcc dot gnu.org
2022-04-19  9:22 ` rguenth at gcc dot gnu.org
2022-04-25 19:26 ` dmalcolm at gcc dot gnu.org
2022-04-25 19:31 ` iains at gcc dot gnu.org
2022-04-28 12:52 ` cvs-commit at gcc dot gnu.org
2022-04-28 12:59 ` iains at gcc dot gnu.org
2022-04-28 15:10 ` [Bug analyzer/105287] [12/13 " dmalcolm at gcc dot gnu.org
2022-04-28 15:58 ` avi at scylladb dot com
2022-04-29  6:36 ` cvs-commit at gcc dot gnu.org
2022-04-29  8:29 ` cvs-commit at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-105287-4-Hcie6SBcsw@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).