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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id BA1483858D29 for ; Mon, 15 Mar 2021 12:28:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BA1483858D29 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-129-LvX060GiM9W6Z90Ci422Zg-1; Mon, 15 Mar 2021 08:28:45 -0400 X-MC-Unique: LvX060GiM9W6Z90Ci422Zg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7CB3C18D6A2C; Mon, 15 Mar 2021 12:28:44 +0000 (UTC) Received: from localhost (unknown [10.33.36.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id F3A9410027C4; Mon, 15 Mar 2021 12:28:43 +0000 (UTC) Date: Mon, 15 Mar 2021 12:28:43 +0000 From: Jonathan Wakely To: Caroline Tice Cc: Jakub Jelinek , libstdc++@gcc.gnu.org, GCC Patches Subject: Re: [PATCH v1] libstdc++-v3: Update VTV vars for libtool link commands [PR99172] Message-ID: <20210315122843.GP3008@redhat.com> References: <20210311162756.GC3008@redhat.com> <20210311163151.GD3008@redhat.com> <20210311164649.GK745611@tucnak> <20210311171033.GE3008@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, 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: Mon, 15 Mar 2021 12:28:49 -0000 On 12/03/21 15:33 -0800, Caroline Tice wrote: >I have updated the patch as you suggested, to filter the >"-fvtable-verify=std" out of AM_CXXFLAGS, and I have verified that it >passes the testsuite with no regressions and fixes the reported bug. This means we also don't pass it to LTCXXCOMPILE, instead of just removing it from CXXLINK as in the original patch. Since I have never understood what libtool is for, I don't really know if that's OK, but if it works then it works. >Is this OK to commit now? OK, thanks. >-- Caroline Tice >cmtice@google.com > >libstdc++-v3/ChangeLog > >2021-03-12 Caroline Tice > > PR libstdc++/99172 > * src/Makefile.am (AM_CXXFLAGS_PRE, AM_CXXFLAGS): Add > AM_CXXFLAGS_PRE with the old definition of AM_CXXFLAGS; make > AM_CXXFLAGS to be AM_CXXFLAGS_PRE with '-fvtable-verify=std' > filtered out. > * src/Makefile.in: Regenerate. > > > >-- Caroline >cmtice@google.com > > >On Thu, Mar 11, 2021 at 9:10 AM Jonathan Wakely wrote: >> >> On 11/03/21 17:46 +0100, Jakub Jelinek via Libstdc++ wrote: >> >On Thu, Mar 11, 2021 at 04:31:51PM +0000, Jonathan Wakely via Gcc-patches wrote: >> >> On 11/03/21 16:27 +0000, Jonathan Wakely wrote: >> >> > That seems cleaner to me, rather than adding another variable with >> >> > minor differences from the existing AM_CXXFLAGS. >> >> >> >> My specific concern is that AM_CXXFLAGS and AM_CXXFLAGS_LT will get >> >> out of sync, i.e. we'll add something to the former and forget to add >> >> it to the latter. >> >> >> >> If we keep using AM_CXXFLAGS but cancel out the -fvtable-verify=std >> >> option, then there aren't two separate variables that can diverge. >> >> >> >> But I think it's too late in the gcc-11 process for that kind of >> >> refactoring. >> > >> >I think $(filter-out -fvtable-verify=std,$(AM_CXXFLAGS)) should be fairly >> >simple thing if that is all that needs to be done. >> >> Yes, we could do that now, and then in stage 1 look at the other >> changes (like moving -Wl,-u options to the link flags not cxxflags). >> >> Using filter-out does assume that no target is going to add anything >> different that should also be filtered out, but that's true as of >> today. >>