From: David Malcolm <dmalcolm@redhat.com>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: New modref/ipa_modref optimization passes
Date: Tue, 22 Sep 2020 16:13:06 -0400 [thread overview]
Message-ID: <705d525d56d62aaff4b56f250b5a755948de740b.camel@redhat.com> (raw)
In-Reply-To: <20200922183912.GE49266@kam.mff.cuni.cz>
On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote:
> David,
> with jit I get the following:
> /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed:
> nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> make[3]: *** [../../gcc/jit/Make-lang.in:121: libgccjit.so.0.0.1]
> Error
>
> Is there a fix/workaround?
I don't recognize that specific error, but googling suggests it may
relate to position-independent code.
Are you configuring with --enable-host-shared ? This is needed when
enabling "jit" in --enable-languages (but slows down the compiler by a
few percent, which is why "jit" isn't in "all").
> Patch I am trying to test/debug is attached, it fixes the selftest
> issue
> and the destructor.
Thanks.
Sadly it doesn't fix the jit crashes, which are now in bugzilla (as PR
jit/97169).
Without the patch, the jit testcases crash at the end of the 1st in-
process iteration, in the dtor for the the new pass.
With the patch the jit testcases crash inside the 3rd in-process
iteration, invoking a modref_summaries finalizer at whichever GC-
collection point happens first, I think, where the modref_summaries *
seems to be pointing at corrupt data:
(gdb) p *(modref_summaries *)p
$2 = {<fast_function_summary<modref_summary*, va_gc>> =
{<function_summary_base<modref_summary>> = {
_vptr.function_summary_base = 0x200000001,
m_symtab_insertion_hook = 0x1, m_symtab_removal_hook = 0x100000004,
m_symtab_duplication_hook = 0x0, m_symtab = 0x644210,
m_insertion_enabled = 112, m_allocator = {m_allocator = {
m_name = 0x0, m_id = 0, m_elts_per_block = 1,
m_returned_free_list = 0x7afafaf01,
m_virgin_free_list = 0xafafafafafaf0001 <error: Cannot access
memory at address 0xafafafafafaf0001>,
m_virgin_elts_remaining = 0, m_elts_allocated =
140737080343888, m_elts_free = 0, m_blocks_allocated = 0,
m_block_list = 0x0, m_elt_size = 6517120, m_size = 13,
m_initialized = false, m_location = {
m_filename = 0x0, m_function = 0x0, m_line = 1, m_origin =
2947481856, m_ggc = false}}}},
m_vector = 0x0}, ipa = false}
I think this latter crash may be a pre-existing bug in how the jit
interacts with gc finalizers. I think the finalizers are accumulating
from in-process run to run, leading to chaos, but I need to debug it
some more to be sure. Alternatively, is there a way that a finalizer
is being registered, and then the object is somehow clobbered without
the finalizer being unregistered from the vec of finalizers?
Dave
next prev parent reply other threads:[~2020-09-22 20:13 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-16 22:23 David Čepelík
2020-09-19 22:32 ` Jan Hubicka
2020-09-20 6:15 ` Jan Hubicka
2020-09-21 7:13 ` Richard Biener
2020-09-21 7:47 ` Jan Hubicka
2020-09-21 7:55 ` Richard Biener
2020-09-21 8:04 ` Jan Hubicka
2020-09-21 8:10 ` Richard Biener
2020-09-22 10:15 ` Tobias Burnus
2020-09-27 21:37 ` Jan Hubicka
2020-10-16 7:56 ` Jan Hubicka
2020-10-16 8:05 ` Richard Biener
2020-10-16 9:20 ` Richard Biener
2020-10-16 10:42 ` Richard Biener
2020-10-23 9:54 ` Bernhard Reutner-Fischer
2020-10-23 10:05 ` Andre Vehreschild
2020-10-29 15:14 ` Jan Hubicka
2020-10-30 8:16 ` Richard Biener
2020-09-20 14:33 ` David Malcolm
2020-09-20 17:30 ` Jan Hubicka
2020-09-20 23:27 ` David Malcolm
2020-09-22 18:47 ` Jan Hubicka
2020-09-22 20:19 ` Jan Hubicka
2020-09-21 23:14 ` David Malcolm
2020-09-22 6:45 ` Jan Hubicka
2020-09-22 7:07 ` Jan Hubicka
2020-09-22 11:21 ` David Malcolm
2020-09-22 12:29 ` Jan Hubicka
2020-09-22 18:39 ` Jan Hubicka
2020-09-22 20:13 ` David Malcolm [this message]
2020-09-22 20:21 ` David Malcolm
2020-09-22 20:24 ` Jan Hubicka
2020-09-22 20:47 ` Issue with ggc_delete and finalizers (was Re: New modref/ipa_modref optimization passes) David Malcolm
2020-09-23 8:31 ` Jan Hubicka
2020-09-24 6:30 ` Jan Hubicka
2020-09-25 14:42 ` David Malcolm
2020-09-22 20:23 ` New modref/ipa_modref optimization passes Jan Hubicka
2020-09-22 21:17 ` David Malcolm
2020-09-22 8:13 ` [committed] ipa: Fix up ipa modref option help texts Jakub Jelinek
2020-09-22 8:47 ` Jakub Jelinek
2020-09-22 9:12 ` Jan Hubicka
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=705d525d56d62aaff4b56f250b5a755948de740b.camel@redhat.com \
--to=dmalcolm@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
/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).