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 9C097385780B for ; Tue, 22 Sep 2020 20:13:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9C097385780B 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-526-gmzFjM4-NSqA4aHAPctuwA-1; Tue, 22 Sep 2020 16:13:08 -0400 X-MC-Unique: gmzFjM4-NSqA4aHAPctuwA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5D6FF6409F; Tue, 22 Sep 2020 20:13:07 +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 EA6C65DA7B; Tue, 22 Sep 2020 20:13:06 +0000 (UTC) Message-ID: <705d525d56d62aaff4b56f250b5a755948de740b.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:13:06 -0400 In-Reply-To: <20200922183912.GE49266@kam.mff.cuni.cz> 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> User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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=-8.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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:13:11 -0000 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 , 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