[9/10 PATCH] Update {x86_64,i?86,powerpc64,s390x,aarch64}-linux baseline_symbols.txt files

H.J. Lu hjl.tools@gmail.com
Fri Apr 26 16:40:00 GMT 2019


On Fri, Apr 26, 2019 at 8:59 AM Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On 26/04/19 15:05 +0100, Jonathan Wakely wrote:
> >On 26/04/19 14:36 +0100, Jonathan Wakely wrote:
> >>On 26/04/19 14:30 +0200, Jakub Jelinek wrote:
> >>>On Fri, Apr 26, 2019 at 01:25:37PM +0100, Jonathan Wakely wrote:
> >>>>On 26/04/19 12:48 +0200, Jakub Jelinek wrote:
> >>>>>Hi!
> >>>>>
> >>>>>The following patch updates the baseline symbols files from April 18th
> >>>>>Fedora rpm build.  I've verified the only added lines are for the
> >>>>>GLIBCXX_3.4.26 or CXXABI_1.3.12 symvers and I don't see any new long double
> >>>>>symbol on powerpc64 or s390x, except I had to manually remove
> >>>>>FUNC:_ZNSbIwSt11char_traitsIwESaIwEE19_M_replace_dispatchIPKcEERS2_N9__gnu_cxx17__normal_iteratorIPwS2_EESA_T_SB_St12__false_type@@GLIBCXX_3.4
> >>>>>lines that started to appear on all but s390x builds in Fedora rpm builds
> >>>>>(but they don't show up e.g. on my workstation).  Guess we need to make the
> >>>>>wildcards more careful.
> >>>>
> >>>>The attached patch would do that. The symbol above is a function
> >>>>template, so we don't need to export it from the lib (because user
> >>>>code that needs it will instantiate it anyway). It's only called from
> >>>>the basic_string<C,T,A>::replace<Iter>(iterator, iterator, Iter, Iter)
> >>>>function template, which isn't exported from the lib.
> >>>
> >>>Thanks, LGTM.
> >>>grep _ZNSbIwSt11char_traitsIwESaIwEE.*_M_replace libstdc++-v3/config/abi/post/*/{,*/}*.txt | grep -v _ZNSbIwSt11char_traitsIwESaIwEE14_M_replace_aux | grep -v _ZNSbIwSt11char_traitsIwESaIwEE15_M_replace_safe
> >>>prints nothing, so the patch looks correct and safe.
> >>>
> >>>Ok for 9.1.
> >>
> >>I tracked down where that symbol was being instantiated, and it's not
> >>needed anyway, and can be suppressed by using if-constexpr. Here's
> >>what I'm going to commit for trunk (after testing finishes).
> >>
> >>This should be safe for the branch too, but we can just make the
> >>linker script change for now and backport this for 9.2 once it's been
> >>on trunk for a while.
> >
> >Here's the final patch I tested and committed to trunk (I had to
> >replace std::-si_same_v with std::is_same because the
> ><bits/locale_conv.h> header is used in C++11 and C++14 too).
> >
> >
>
> >commit 7ef6887dab4368b82b1cda06775dcd5810e3c479
> >Author: Jonathan Wakely <jwakely@redhat.com>
> >Date:   Fri Apr 26 14:23:09 2019 +0100
> >
> >    Reduce code instantiated by filesystem::path::_S_convert_loc
> >
> >    Jakub noted in https://gcc.gnu.org/ml/libstdc++/2019-04/msg00140.html
> >    that an unwanted std::wstring::_M_replace_dispatch symbol has started to
> >    be exported from the Fedora shared library. This symbol is triggered by
> >    the instantiation of std::wstring::assign(const char*, const char*) from
> >    std::__str_codecvt_in which is called from path::_S_convert_loc. The
> >    branch that triggers that instantiation can't actually happen in that
> >    case, because codecvt facets will only return noconv when the input and
> >    output types are the same. Guarding the assign call with an if-constexpr
> >    check that the types are the same avoids instantiating template
> >    specializations that will never actually be needed.
> >
> >            * config/abi/pre/gnu.ver (GLIBCXX_3.4): Replace wildcard that matches
> >            wstring::_M_replace_dispatch with more specific patterns.
> >            * include/bits/fs_path.h (path::_S_convert_loc<_InputIterator>):
> >            Create const std::string to avoid redundant call to _S_convert_loc
> >            with non-const pointers.
>
> We can do that part for experimental::filesystem::path too.
>
> Tested x86_64-linux, committed to trunk.
>
> >            * include/bits/locale_conv.h (__do_str_codecvt): Use if-constexpr to
> >            avoid unnecessary basic_string::assign instantiations.
>
>

Here is the patch for x32.  OK for trunk and for 9.1?

Thanks.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-x32-Update-baseline_symbols.txt.patch
Type: text/x-patch
Size: 81335 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20190426/090ad301/attachment.bin>


More information about the Gcc-patches mailing list