public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ppalka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/99479] [modules] ICE Aborted signal terminated program cc1plus
Date: Mon, 24 Jan 2022 15:52:25 +0000	[thread overview]
Message-ID: <bug-99479-4-Qmbkqaf47j@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-99479-4@http.gcc.gnu.org/bugzilla/>

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

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

--- Comment #20 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #19)
> Created attachment 52106 [details]
> reduced testcase
> 
> Not even though it says PR 100129, this is the reduced testcase.
> just execute t.sh which does:
> gcc header.hh -std=c++20 -fmodules-ts
> gcc t.cc -std=c++20 -fmodules-ts -wrapper valgrind,--error-exitcode=1
> 
> And you will see the valgrind failures.

Looks like name_lookup::search_unqualified uses a static vector under the
assumption that the function isn't recursive:

  /* Make static to avoid continual reallocation.  We're not
     recursive.  */
  static using_queue *queue = NULL;

but with modules, this assumption appears to be untrue:

#0  name_lookup::search_unqualified (this=0x7fffffffcde0, scope=<namespace_decl
0x7ffff7263098 std>, level=0x7ffff73ba048) at
/home/patrick/code/gcc/gcc/cp/name-lookup.cc:1133
#1  0x0000000000aa33f5 in lookup_name (name=name@entry=<identifier_node
0x7ffff7261980 operator delete>, where=<optimized out>,
where@entry=LOOK_where::BLOCK_NAMESPACE, want=want@entry=LOOK_want::NORMAL)
    at /home/patrick/code/gcc/gcc/cp/name-lookup.cc:7736
#2  0x00000000009492be in build_op_delete_call (code=code@entry=DELETE_EXPR,
addr=<parm_decl 0x7ffff7fc5180 this>, size=<integer_cst 0x7ffff73b9150>,
global_p=global_p@entry=false, 
    placement=placement@entry=<tree 0x0>, alloc_fn=alloc_fn@entry=<tree 0x0>,
complain=3) at /home/patrick/code/gcc/gcc/cp/call.cc:7264
#3  0x0000000000aa9e63 in build_delete_destructor_body
(delete_dtor=<function_decl 0x7ffff7399800 __dt_del >,
complete_dtor=<function_decl 0x7ffff7399900 __dt_comp >)
    at /home/patrick/code/gcc/gcc/cp/optimize.cc:139
#4  0x0000000000aab5f9 in maybe_clone_body (fn=fn@entry=<function_decl
0x7ffff7399700 __dt >) at /home/patrick/code/gcc/gcc/cp/optimize.cc:592
#5  0x0000000000a678f8 in post_load_processing () at
/home/patrick/code/gcc/gcc/cp/module.cc:17185
#6  0x0000000000a8e61a in lazy_load_binding (mod=<optimized out>,
ns=ns@entry=<namespace_decl 0x7ffff7263098 std>, id=<identifier_node
0x7ffff7260b40 atomic>, mslot=mslot@entry=0x7ffff73a9d30)
    at /home/patrick/code/gcc/gcc/cp/module.cc:18792
#7  0x0000000000aa000f in name_lookup::search_namespace_only
(this=0x7fffffffd210, scope=<namespace_decl 0x7ffff7263098 std>) at
/home/patrick/code/gcc/gcc/cp/name-lookup.cc:927
#8  0x0000000000aa165c in name_lookup::search_unqualified (this=0x7fffffffd210,
scope=<namespace_decl 0x7ffff7263098 std>, level=<optimized out>) at
/home/patrick/code/gcc/gcc/cp/name-lookup.cc:1155
...

Using a non-static vector fixes the valgrind error.  Is this a fix that's worth
applying at this point?

  parent reply	other threads:[~2022-01-24 15:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-09  7:37 [Bug c++/99479] New: " alexander.lelyakin at googlemail dot com
2021-03-11  8:16 ` [Bug c++/99479] " alexander.lelyakin at googlemail dot com
2021-03-12 10:18 ` alexander.lelyakin at googlemail dot com
2021-03-23  8:48 ` alexander.lelyakin at googlemail dot com
2021-03-23 20:11 ` alexander.lelyakin at googlemail dot com
2021-03-24 19:44 ` alexander.lelyakin at googlemail dot com
2021-03-27  6:44 ` alexander.lelyakin at googlemail dot com
2021-03-30  1:25 ` mpolacek at gcc dot gnu.org
2021-03-30  6:43 ` alexander.lelyakin at googlemail dot com
2021-04-16 18:51 ` alexander.lelyakin at googlemail dot com
2021-04-16 18:53 ` alexander.lelyakin at googlemail dot com
2021-12-30 16:09 ` pinskia at gcc dot gnu.org
2021-12-30 16:10 ` pinskia at gcc dot gnu.org
2021-12-30 16:11 ` pinskia at gcc dot gnu.org
2021-12-30 16:12 ` pinskia at gcc dot gnu.org
2021-12-30 16:12 ` pinskia at gcc dot gnu.org
2021-12-30 16:12 ` pinskia at gcc dot gnu.org
2021-12-30 21:34 ` pinskia at gcc dot gnu.org
2021-12-31  4:13 ` pinskia at gcc dot gnu.org
2021-12-31  4:20 ` pinskia at gcc dot gnu.org
2022-01-01  4:09 ` pinskia at gcc dot gnu.org
2022-01-24 15:52 ` ppalka at gcc dot gnu.org [this message]
2022-01-24 17:56 ` pinskia at gcc dot gnu.org
2022-04-07 20:10 ` cvs-commit at gcc dot gnu.org
2022-10-20 12:57 ` LpSolit at gmail dot com

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-99479-4-Qmbkqaf47j@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).