From patchwork Wed Oct 22 15:22:43 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Malcolm X-Patchwork-Id: 402189 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 495BB140088 for ; Thu, 23 Oct 2014 02:26:57 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:cc:date:content-type:mime-version; q=dns; s=default; b=maDAsNwmLH7HNfmLmTsbR/PKdy3VkZCzY+KcNzy2LI0 iWKqVoU1Mf1tnDvvx2ur7TG79M48kuNSDysgE+7eFEKKppZDMIwKmX5Y1cDWNwLz 6IaUcdvpoEqNuEjYSKT/uhRzl0EsPmzNPj6+rZyz3G2OhjZcs6zB1CJEQXYA84ZM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:cc:date:content-type:mime-version; s=default; bh=UYB9jT2ZaRpPCZ5BB2/Pq/JKaBk=; b=qatKDm6XzCv7IOFRX jsDzYPi3AmDhRJd2HJEMqnIFg8OSx2EHhYRlFfvgCg1O62i2JUiyO7VKGA3XmIiX YtAEWD/tzmgerxStQeqp9P2pbdQWW85+uRlUYqVHUn/y1hBjL6Jfst3qOAN0cxlh JA2z1uPfdWUBWSih76RhrPlLGg= Received: (qmail 27819 invoked by alias); 22 Oct 2014 15:26:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 27801 invoked by uid 89); 22 Oct 2014 15:26:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 22 Oct 2014 15:26:48 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9MFQkCD006567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 22 Oct 2014 11:26:46 -0400 Received: from [10.3.235.100] (vpn-235-100.phx2.redhat.com [10.3.235.100]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9MFQjal011088; Wed, 22 Oct 2014 11:26:46 -0400 Message-ID: <1413991363.9513.280.camel@surprise> Subject: [PATCH, committed] Reset ipa-icf.c:optimizer to NULL when done From: David Malcolm To: Jan Hubicka , Martin Liska Cc: "gcc-patches@gcc.gnu.org" Date: Wed, 22 Oct 2014 11:22:43 -0400 Mime-Version: 1.0 X-IsSubscribed: yes After a recent merge of trunk to the jit branch that brought in ipa-icf, the new pass was segfaulting on the second iteration of an in-process compile; e.g. with: test-factorial.exe: internal compiler error: Segmentation fault 0x7f3f20c2301a crash_signal ../../src/gcc/toplev.c:349 0x7f3f207e963e bitmap_initialize_stat ../../src/gcc/bitmap.h:277 0x7f3f207e963e bitmap_obstack_alloc_stat(bitmap_obstack*) ../../src/gcc/bitmap.c:377 0x7f3f21360acb ipa_icf::sem_item::setup(bitmap_obstack*) ../../src/gcc/ipa-icf.c:142 0x7f3f2136099d ipa_icf::sem_item::sem_item(ipa_icf::sem_item_type, symtab_node*, unsigned int, bitmap_obstack*) ../../src/gcc/ipa-icf.c:116 0x7f3f21360e41 ipa_icf::sem_function::sem_function(cgraph_node*, unsigned int, bitmap_obstack*) ../../src/gcc/ipa-icf.c:192 0x7f3f21363012 ipa_icf::sem_function::parse(cgraph_node*, bitmap_obstack*) ../../src/gcc/ipa-icf.c:803 0x7f3f21365911 ipa_icf::sem_item_optimizer::parse_funcs_and_vars() ../../src/gcc/ipa-icf.c:1619 0x7f3f21367cb5 ipa_icf_generate_summary ../../src/gcc/ipa-icf.c:2287 0x7f3f20b5eaa4 execute_ipa_summary_passes(ipa_opt_pass_d*) ../../src/gcc/passes.c:1952 0x7f3f20826ce8 ipa_passes ../../src/gcc/cgraphunit.c:2043 0x7f3f2082706a symbol_table::compile() ../../src/gcc/cgraphunit.c:2137 0x7f3f20827400 symbol_table::finalize_compilation_unit() ../../src/gcc/cgraphunit.c:2290 0x7f3f207bf73c jit_langhook_write_globals ../../src/gcc/jit/dummy-frontend.c:212 This turns out to be a use-after-delete: the "optimizer" singleton was not being reset to NULL after being deleted, so on subsequent in-process invocations of toplev::main the new instance of the pass_ipa_icf was using the deleted memory from the previous compile. The one-liner solution I applied to the jit branch was to simply reset the ptr to NULL after deleting it to ensure that a fresh sem_item_optimizer gets built on each in-process compile. Attached is a version of that jit patch, that I've now committed to trunk. Bootstrapped on x86_64-unknown-linux-gnu (Fedora 20). Committed to trunk as r216561, since this seems obvious. A more involved solution might be to eliminate this singleton in favor of making it instance data of the class pass_ipa_icf, but that would involved making the IPA hooks be vfuncs, so not doing that for now. The other new piece of global state in ipa-icf.c is: unsigned int sem_item_optimizer::class_id = 0; Honza, Martin: is there any reason that class_id is static, rather that being instance data of the sem_item_optimizer instance? As far as I can see, it's only ever accessed from sem_item_optimizer methods. Though the jit branch's testsuite seems to work OK if I don't bother resetting it back to 0... Thanks Dave Index: gcc/ChangeLog =================================================================== --- gcc/ChangeLog (revision 216560) +++ gcc/ChangeLog (revision 216561) @@ -1,3 +1,7 @@ +2014-10-22 David Malcolm + + * ipa-icf.c (ipa_icf_driver): Set optimizer to NULL when done. + 2014-10-22 Andrew MacLeod * cfgbuild.h: New. Add prototypes for cfgbuild.c. Index: gcc/ipa-icf.c =================================================================== --- gcc/ipa-icf.c (revision 216560) +++ gcc/ipa-icf.c (revision 216561) @@ -2320,6 +2320,7 @@ optimizer->unregister_hooks (); delete optimizer; + optimizer = NULL; return 0; }