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.
Is this OK to commit now?
-- Caroline Tice
cmt...@google.com
libstdc++-v3/ChangeLog
2021-03-12 Caroline Tice <cmt...@google.com>
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
cmt...@google.com
On Thu, Mar 11, 2021 at 9:10 AM Jonathan Wakely <jwak...@redhat.com> 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.
>
v2-0001-libstdc-v3-Update-VTV-vars-for-libtool-link-comma.patch
Description: Binary data
