From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28120 invoked by alias); 20 Feb 2019 14:31:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 28027 invoked by uid 89); 20 Feb 2019 14:31:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Feb 2019 14:31:05 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A8640ADA3; Wed, 20 Feb 2019 14:30:52 +0000 (UTC) Date: Wed, 20 Feb 2019 14:35:00 -0000 From: Richard Biener To: Caroline Tice cc: GCC Patches , Jason Merrill Subject: Re: [PATCH][C++] Fix ICE with VTV In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2019-02/txt/msg01666.txt.bz2 On Tue, 19 Feb 2019, Caroline Tice wrote: > On Tue, Feb 19, 2019 at 1:57 AM Richard Biener wrote: > > > > > Looks like vtv_generate_init_routine calls symtab->process_new_functions > > () which has seriously bad effects on GCCs internal memory state. > > > > VTV has zero testsuite coverage it seems and besides its initial > > commit didn't receive any love. > > > > I am puzzled by these statements, as neither of them is true. VTV does > have a testsuite in the libvtv directory. Naturally you can only run them > when vtv is enabled and only from the libvtv build tree, as they will all > fail if VTV is not enabled. I have fixed various bugs in VTV since the > initial commit, and I have also approved several patches, especially for > people migrating it to other architectures, suggesting that interest in it > is not zero. > > > > > > > Can we rip it out please? > > > > Is the patch OK? (Pointless) bootstrap and regtest running on > > x86_64-unknown-linux-gnu. > > > > Has anybody "recently" tried to enable the feature and tested the > > result? > > > > I have not tried building it recently, but will do so. I will review your > patch to see if it makes sense. I would prefer that VTV not be 'ripped > out' of GCC, and will do whatever I can, within reason, to try to fix its > issues. Meanwhile the patch passed bootstrap and testing with --enable-vtable-verify. Richard. > > > > > Thanks, > > Richard. > > > > 2019-02-19 Richard Biener > > > > PR middle-end/89392 > > cp/ > > * vtable-class-hierarchy.c (vtv_generate_init_routine): Do not > > make symtab process new functions here. > > > > Index: gcc/cp/vtable-class-hierarchy.c > > =================================================================== > > --- gcc/cp/vtable-class-hierarchy.c (revision 269009) > > +++ gcc/cp/vtable-class-hierarchy.c (working copy) > > @@ -1191,8 +1191,6 @@ vtv_generate_init_routine (void) > > gimplify_function_tree (vtv_fndecl); > > cgraph_node::add_new_function (vtv_fndecl, false); > > > > - symtab->process_new_functions (); > > - > > if (flag_vtable_verify == VTV_PREINIT_PRIORITY && !TARGET_PECOFF) > > assemble_vtv_preinit_initializer (vtv_fndecl); > > > > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)