From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 93E77386F430 for ; Tue, 22 Sep 2020 20:21:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 93E77386F430 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-584-shvgwUqMPZCCCcvKDXrPJA-1; Tue, 22 Sep 2020 16:21:30 -0400 X-MC-Unique: shvgwUqMPZCCCcvKDXrPJA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 868F118B9F42; Tue, 22 Sep 2020 20:21:29 +0000 (UTC) Received: from ovpn-112-230.phx2.redhat.com (ovpn-112-230.phx2.redhat.com [10.3.112.230]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1FB051A835; Tue, 22 Sep 2020 20:21:29 +0000 (UTC) Message-ID: <45ebbb6c3227dc592823e96e69d82dcd53322aea.camel@redhat.com> Subject: Re: New modref/ipa_modref optimization passes From: David Malcolm To: Jan Hubicka Cc: gcc-patches@gcc.gnu.org Date: Tue, 22 Sep 2020 16:21:28 -0400 In-Reply-To: <705d525d56d62aaff4b56f250b5a755948de740b.camel@redhat.com> References: <157394261677.27454.2367573047582814412@a285.localdomain> <20200919223255.GA69342@kam.mff.cuni.cz> <20200920173043.GD6758@kam.mff.cuni.cz> <9597b8e20d5b50ad4e501d4506e578107474d55f.camel@redhat.com> <20200922064545.GF91738@kam.mff.cuni.cz> <20200922070731.GA15864@kam.mff.cuni.cz> <6a8bf0b30fff9059afc2c5f7af13b863e3c93dad.camel@redhat.com> <20200922183912.GE49266@kam.mff.cuni.cz> <705d525d56d62aaff4b56f250b5a755948de740b.camel@redhat.com> User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 20:21:33 -0000 On Tue, 2020-09-22 at 16:13 -0400, David Malcolm wrote: > 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 = {> = > {> = { > _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 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? Aha: this patch on top of yours seems to fix it, at least for the test I've been debugging. Calling gcc_delete on something seems to delete it without removing the finalizer, leaving the finalizer around to run on whatever the memory eventually gets reused for, leading to segfaults: diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c index 4b9c4db4ee9..64d314321cb 100644 --- a/gcc/ipa-modref.c +++ b/gcc/ipa-modref.c @@ -1372,8 +1372,6 @@ unsigned int pass_ipa_modref::execute (function *) void ipa_modref_c_finalize () { - if (summaries) - ggc_delete (summaries); summaries = NULL; }