Re: [PATCH, GCC/LTO, ping] Fix PR69866: LTO with def for weak alias in regular object file
> The new test fails on darwin with the usual
>
> FAIL: gcc.dg/lto/pr69866 c_lto_pr69866_0.o-c_lto_pr69866_1.o link, -O0 -flto
> -flto-partition=none
>
> IMO it requires a
>
> /* { dg-require-alias "" } */
Yep,I will add it shortly.
Honza
>
> directive.
>
> TIA
>
> Dominique
[patch][ping #2] Fix PR80929: Realistic PARALLEL cost in seq_cost.
Ping #2 https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00096.html On 02.06.2017 09:53, Georg-Johann Lay wrote: > Hi, > > this small addition improves costs of PARALLELs in > rtlanal.c:seq_cost(). Up to now, these costs are > assumed to be 1 which gives gross inexact costs for, > e.g. divmod which is represented as PARALLEL. > > The patch just forwards cost computation to insn_rtx_cost > which uses the cost of the 1st SET (if any) and otherwise > assign costs of 1 insn. > > Bootstrapped & regtested on x86_64. > > Moreover, it fixed the division by constant on avr where > the problem popped up since PR79665. > > Ok to install? > > Johann > > gcc/ > PR middle-end/80929 > * rtlanal.c (seq_cost) [PARALLEL]: Get cost from insn_rtx_cost > instead of assuming cost of 1.
Re: [Patch] Forward triviality in variant
Besides the changes on the comments, I also changed the definition of
_S_trivial_copy_assign and _S_trivial_move_assign to match what union
has. See [class.copy.assign]p9.
On Thu, Jun 1, 2017 at 8:13 AM, Jonathan Wakely wrote:
> On 30/05/17 02:16 -0700, Tim Shen via libstdc++ wrote:
>>
>> diff --git a/libstdc++-v3/include/std/variant
>> b/libstdc++-v3/include/std/variant
>> index b9824a5182c..f81b815af09 100644
>> --- a/libstdc++-v3/include/std/variant
>> +++ b/libstdc++-v3/include/std/variant
>> @@ -290,6 +290,53 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> __ref_cast<_Tp>(__t));
>> }
>>
>> + template
>> +struct _Traits
>> +{
>> + static constexpr bool is_default_constructible_v =
>> + is_default_constructible_v> _Types...>::type>;
>> + static constexpr bool is_copy_constructible_v =
>> + __and_...>::value;
>> + static constexpr bool is_move_constructible_v =
>> + __and_...>::value;
>> + static constexpr bool is_copy_assignable_v =
>> + is_copy_constructible_v && is_move_constructible_v
>> + && __and_...>::value;
>> + static constexpr bool is_move_assignable_v =
>> + is_move_constructible_v
>> + && __and_...>::value;
>
>
> It seems strange to me that these ones end with _v but the following
> ones don't. Could we make them all have no _v suffix?
Done. They are internal traits only for readability, so I shortened
the names and make them libstdc++ style, e.g. _S_copy_ctor.
>
>> + static constexpr bool is_dtor_trivial =
>> + __and_...>::value;
>> + static constexpr bool is_copy_ctor_trivial =
>> + __and_...>::value;
>> + static constexpr bool is_move_ctor_trivial =
>> + __and_...>::value;
>> + static constexpr bool is_copy_assign_trivial =
>> + is_dtor_trivial
>> + && is_copy_ctor_trivial
>> + && __and_...>::value;
>> + static constexpr bool is_move_assign_trivial =
>> + is_dtor_trivial
>> + && is_move_ctor_trivial
>> + && __and_...>::value;
>> +
>> + static constexpr bool is_default_ctor_noexcept =
>> + is_nothrow_default_constructible_v<
>> + typename _Nth_type<0, _Types...>::type>;
>> + static constexpr bool is_copy_ctor_noexcept =
>> + is_copy_ctor_trivial;
>> + static constexpr bool is_move_ctor_noexcept =
>> + is_move_ctor_trivial
>> + || __and_...>::value;
>> + static constexpr bool is_copy_assign_noexcept =
>> + is_copy_assign_trivial;
>> + static constexpr bool is_move_assign_noexcept =
>> + is_move_assign_trivial ||
>> + (is_move_ctor_noexcept
>> + && __and_...>::value);
>> +};
>
>
> Does using __and_ for any of those traits reduce the limit on the
> number of alternatives in a variant? We switched to using fold
> expressions in some contexts to avoid very deep instantiations, but I
> don't know if these will hit the same problem, but it looks like it
> will.
Done, use fold expression instead. At one point we changed some fold
expressions to __and_, because __and_ has short circuiting; does fold
expressions have short circuits too? Now that I think about it, short
circuiting in a constant fold expression should be a QoI issue.
>> @@ -928,12 +1107,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> static constexpr size_t __index_of =
>> __detail::__variant::__index_of_v<_Tp, _Types...>;
>>
>> + using _Traits = __detail::__variant::_Traits<_Types...>;
>> +
>> public:
>> - constexpr variant()
>> - noexcept(is_nothrow_default_constructible_v<__to_type<0>>) =
>> default;
>> - variant(const variant&) = default;
>> + variant() noexcept(_Traits::is_default_ctor_noexcept) = default;
>
>
> Do we need the exception specifications here? Will the =default make
> the right thing happen anyway? (And if not, won't we get an error by
> trying to define the constructors as noexcept when the implicit
> definition would not be noexcept?)
Done. Removed unnecessary noexcept qualifiers.
It turns out I mistakenly thought using "variant() = default" means
`variant() noexcept(false) = default`.
--
Regards,
Tim Shen
commit 919492daf1c5ff78de4a33bdae265ea1acacc446
Author: Tim Shen
Date: Mon May 29 22:44:42 2017 -0700
2017-05-30 Tim Shen
PR libstdc++/80187
* include/std/variant (variant::variant, variant::~variant,
variant::operator=): Implement triviality forwarding for four
special member functions.
* testsuite/20_util/variant/compile.cc: Tests.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index b9824a5182c..ef0cba98388 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -290,6 +290,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__ref_cast<_Tp>(__t));
}
+ template
+struct _Traits
+{
+ static cons
Re: [committed, PATCH] x32: Update baseline_symbols.txt
On Sun, Jun 18, 2017 at 10:38 AM, Jakub Jelinek wrote: > On Sun, Jun 18, 2017 at 09:45:39AM -0700, H.J. Lu wrote: >> PR libstdc++/81092 >> * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated. >> --- >> libstdc++-v3/ChangeLog | 5 >> + >> .../config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt| 5 >> + >> 2 files changed, 10 insertions(+) >> >> diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog >> index aad8ed4..eebb326 100644 >> --- a/libstdc++-v3/ChangeLog >> +++ b/libstdc++-v3/ChangeLog >> @@ -1,3 +1,8 @@ >> +2017-06-18 H.J. Lu >> + >> + PR libstdc++/81092 >> + * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated. >> + >> 2017-06-18 Andreas Schwab > > Could you please also update gcc-7-branch? > It doesn't have the: > >> +FUNC:_ZNKSt13random_device13_M_getentropyEv@@GLIBCXX_3.4.25 >> +OBJECT:0:GLIBCXX_3.4.25 > > entries but the rest should be there. Thanks. This is what I checked in. -- H.J. From 11a7d1403c5cdb081dfc5dcae2cf0f265e8cf3f7 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Sun, 18 Jun 2017 11:58:29 -0700 Subject: [PATCH] x32: Update baseline_symbols.txt PR libstdc++/81092 * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated. --- libstdc++-v3/ChangeLog | 5 + .../config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt| 3 +++ 2 files changed, 8 insertions(+) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 35e16e1..ba8a585 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,8 @@ +2017-06-18 H.J. Lu + + PR libstdc++/81092 + * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated. + 2017-06-16 Jakub Jelinek PR libstdc++/81092 diff --git a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt index 74e486e..bdc4583 100644 --- a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt +++ b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt @@ -1329,6 +1329,7 @@ FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1EPKwRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1EPKwjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_@@GLIBCXX_3.4 +FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jRKS1_@@GLIBCXX_3.4.24 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jj@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ESt16initializer_listIwERKS1_@@GLIBCXX_3.4.11 @@ -1342,6 +1343,7 @@ FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2EPKwRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2EPKwjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_@@GLIBCXX_3.4 +FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_jRKS1_@@GLIBCXX_3.4.24 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_jj@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_jjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ESt16initializer_listIwERKS1_@@GLIBCXX_3.4.11 @@ -4002,6 +4004,7 @@ OBJECT:0:GLIBCXX_3.4.20 OBJECT:0:GLIBCXX_3.4.21 OBJECT:0:GLIBCXX_3.4.22 OBJECT:0:GLIBCXX_3.4.23 +OBJECT:0:GLIBCXX_3.4.24 OBJECT:0:GLIBCXX_3.4.3 OBJECT:0:GLIBCXX_3.4.4 OBJECT:0:GLIBCXX_3.4.5 -- 2.9.4
Re: [patch, libfortran] Speed up cshift for dim > 1
Hi Jerry, OK for trunk. Committed as r249350. Thanks for the review, and thanks to Dominique for testing. Doing the same for eoshift should be straightforward, I'll do that later (but certainly before the 8.1 release). Next, on to cshift with an array as shift. I have some ideas there, let's see how that works out. Regards Thomas
Re: [PATCH 2/2] i386: Assume Skylake for unknown models with clflushopt
On Fri, Jun 16, 2017 at 11:42 PM, Matt Turner wrote: > gcc/ > * config/i386/driver-i386.c (host_detect_local_cpu): Assume > skylake for unknown models with clflushopt. Also OK. Thanks, Uros. > --- > gcc/config/i386/driver-i386.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c > index 09faad0af0e..570c49031bd 100644 > --- a/gcc/config/i386/driver-i386.c > +++ b/gcc/config/i386/driver-i386.c > @@ -797,6 +797,9 @@ const char *host_detect_local_cpu (int argc, const char > **argv) > /* Assume Knights Landing. */ > if (has_avx512f) > cpu = "knl"; > + /* Assume Skylake. */ > + else if (has_clflushopt) > + cpu = "skylake"; > /* Assume Broadwell. */ > else if (has_adx) > cpu = "broadwell"; > -- > 2.13.0 >
Re: [PATCH 1/2] i386: Consider Kaby Lake to be equivalent to Skylake
On Fri, Jun 16, 2017 at 11:42 PM, Matt Turner wrote:
> Currently -march=native selects -march=broadwell on Kaby Lake systems,
> since its model numbers are missing from the switch statement. It falls
> back to the default case and chooses -march=broadwell because of the
> presence of the ADX instruction set.
>
> gcc/
> * config/i386/driver-i386.c (host_detect_local_cpu): Add Kaby
> Lake models to skylake case.
>
> gcc/testsuite/
>
> * gcc.target/i386/builtin_target.c: Add Kaby Lake models to
> skylake check.
>
> libgcc/
>
> * config/i386/cpuinfo.c (get_intel_cpu): Add Kaby Lake models to
> skylake case.
OK.
Thanks,
Uros.
> ---
> gcc/config/i386/driver-i386.c | 3 +++
> gcc/testsuite/gcc.target/i386/builtin_target.c | 3 +++
> libgcc/config/i386/cpuinfo.c | 3 +++
> 3 files changed, 9 insertions(+)
>
> diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
> index 6c812514239..09faad0af0e 100644
> --- a/gcc/config/i386/driver-i386.c
> +++ b/gcc/config/i386/driver-i386.c
> @@ -781,6 +781,9 @@ const char *host_detect_local_cpu (int argc, const char
> **argv)
> case 0x4e:
> case 0x5e:
> /* Skylake. */
> + case 0x8e:
> + case 0x9e:
> + /* Kaby Lake. */
> cpu = "skylake";
> break;
> case 0x57:
> diff --git a/gcc/testsuite/gcc.target/i386/builtin_target.c
> b/gcc/testsuite/gcc.target/i386/builtin_target.c
> index 374f0292453..9c190eb7ebc 100644
> --- a/gcc/testsuite/gcc.target/i386/builtin_target.c
> +++ b/gcc/testsuite/gcc.target/i386/builtin_target.c
> @@ -88,6 +88,9 @@ check_intel_cpu_model (unsigned int family, unsigned int
> model,
> case 0x4e:
> case 0x5e:
> /* Skylake. */
> + case 0x8e:
> + case 0x9e:
> + /* Kaby Lake. */
> assert (__builtin_cpu_is ("corei7"));
> assert (__builtin_cpu_is ("skylake"));
> break;
> diff --git a/libgcc/config/i386/cpuinfo.c b/libgcc/config/i386/cpuinfo.c
> index a1dc011525f..b008fb6e396 100644
> --- a/libgcc/config/i386/cpuinfo.c
> +++ b/libgcc/config/i386/cpuinfo.c
> @@ -183,6 +183,9 @@ get_intel_cpu (unsigned int family, unsigned int model,
> unsigned int brand_id)
> case 0x4e:
> case 0x5e:
> /* Skylake. */
> + case 0x8e:
> + case 0x9e:
> + /* Kaby Lake. */
> __cpu_model.__cpu_type = INTEL_COREI7;
> __cpu_model.__cpu_subtype = INTEL_COREI7_SKYLAKE;
> break;
> --
> 2.13.0
>
Re: [committed, PATCH] x32: Update baseline_symbols.txt
On Sun, Jun 18, 2017 at 09:45:39AM -0700, H.J. Lu wrote: > PR libstdc++/81092 > * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated. > --- > libstdc++-v3/ChangeLog | 5 > + > .../config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt| 5 > + > 2 files changed, 10 insertions(+) > > diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog > index aad8ed4..eebb326 100644 > --- a/libstdc++-v3/ChangeLog > +++ b/libstdc++-v3/ChangeLog > @@ -1,3 +1,8 @@ > +2017-06-18 H.J. Lu > + > + PR libstdc++/81092 > + * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated. > + > 2017-06-18 Andreas Schwab Could you please also update gcc-7-branch? It doesn't have the: > +FUNC:_ZNKSt13random_device13_M_getentropyEv@@GLIBCXX_3.4.25 > +OBJECT:0:GLIBCXX_3.4.25 entries but the rest should be there. Jakub
[committed, PATCH] x32: Update baseline_symbols.txt
PR libstdc++/81092 * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated. --- libstdc++-v3/ChangeLog | 5 + .../config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt| 5 + 2 files changed, 10 insertions(+) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index aad8ed4..eebb326 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,8 @@ +2017-06-18 H.J. Lu + + PR libstdc++/81092 + * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated. + 2017-06-18 Andreas Schwab PR libstdc++/81092 diff --git a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt index 74e486e..6e73a3d 100644 --- a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt +++ b/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt @@ -444,6 +444,7 @@ FUNC:_ZNKSt13basic_fstreamIwSt11char_traitsIwEE7is_openEv@GLIBCXX_3.4 FUNC:_ZNKSt13basic_istreamIwSt11char_traitsIwEE6gcountEv@@GLIBCXX_3.4 FUNC:_ZNKSt13basic_istreamIwSt11char_traitsIwEE6sentrycvbEv@@GLIBCXX_3.4 FUNC:_ZNKSt13basic_ostreamIwSt11char_traitsIwEE6sentrycvbEv@@GLIBCXX_3.4 +FUNC:_ZNKSt13random_device13_M_getentropyEv@@GLIBCXX_3.4.25 FUNC:_ZNKSt13runtime_error4whatEv@@GLIBCXX_3.4 FUNC:_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE5rdbufEv@@GLIBCXX_3.4 FUNC:_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5 @@ -1329,6 +1330,7 @@ FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1EPKwRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1EPKwjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_@@GLIBCXX_3.4 +FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jRKS1_@@GLIBCXX_3.4.24 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jj@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ESt16initializer_listIwERKS1_@@GLIBCXX_3.4.11 @@ -1342,6 +1344,7 @@ FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2EPKwRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2EPKwjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_@@GLIBCXX_3.4 +FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_jRKS1_@@GLIBCXX_3.4.24 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_jj@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_jjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ESt16initializer_listIwERKS1_@@GLIBCXX_3.4.11 @@ -4002,6 +4005,8 @@ OBJECT:0:GLIBCXX_3.4.20 OBJECT:0:GLIBCXX_3.4.21 OBJECT:0:GLIBCXX_3.4.22 OBJECT:0:GLIBCXX_3.4.23 +OBJECT:0:GLIBCXX_3.4.24 +OBJECT:0:GLIBCXX_3.4.25 OBJECT:0:GLIBCXX_3.4.3 OBJECT:0:GLIBCXX_3.4.4 OBJECT:0:GLIBCXX_3.4.5 -- 2.9.4
m68k: update libstdc++ baseline symbols
PR libstdc++/81092 * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update. diff --git a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt index 8ffc720d55..2af971a569 100644 --- a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt +++ b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt @@ -444,7 +444,7 @@ FUNC:_ZNKSt13basic_fstreamIwSt11char_traitsIwEE7is_openEv@GLIBCXX_3.4 FUNC:_ZNKSt13basic_istreamIwSt11char_traitsIwEE6gcountEv@@GLIBCXX_3.4 FUNC:_ZNKSt13basic_istreamIwSt11char_traitsIwEE6sentrycvbEv@@GLIBCXX_3.4 FUNC:_ZNKSt13basic_ostreamIwSt11char_traitsIwEE6sentrycvbEv@@GLIBCXX_3.4 -FUNC:_ZNKSt13random_device13_M_getentropyEv@@GLIBCXX_3.4.24 +FUNC:_ZNKSt13random_device13_M_getentropyEv@@GLIBCXX_3.4.25 FUNC:_ZNKSt13runtime_error4whatEv@@GLIBCXX_3.4 FUNC:_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE5rdbufEv@@GLIBCXX_3.4 FUNC:_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5 @@ -1330,6 +1330,7 @@ FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1EPKwRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1EPKwjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_@@GLIBCXX_3.4 +FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jRKS1_@@GLIBCXX_3.4.24 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jj@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC1ESt16initializer_listIwERKS1_@@GLIBCXX_3.4.11 @@ -1343,6 +1344,7 @@ FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2EPKwRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2EPKwjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_@@GLIBCXX_3.4 +FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_jRKS1_@@GLIBCXX_3.4.24 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_jj@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_jjRKS1_@@GLIBCXX_3.4 FUNC:_ZNSbIwSt11char_traitsIwESaIwEEC2ESt16initializer_listIwERKS1_@@GLIBCXX_3.4.11 @@ -4003,6 +4005,7 @@ OBJECT:0:GLIBCXX_3.4.21 OBJECT:0:GLIBCXX_3.4.22 OBJECT:0:GLIBCXX_3.4.23 OBJECT:0:GLIBCXX_3.4.24 +OBJECT:0:GLIBCXX_3.4.25 OBJECT:0:GLIBCXX_3.4.3 OBJECT:0:GLIBCXX_3.4.4 OBJECT:0:GLIBCXX_3.4.5 -- 2.13.1 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace
On 16.06.2017 17:39, Denis Khalikov wrote: > Hello everyone, > > This is a patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631 > > Can some one please review attached patch. not a full review, but it looks like the system debug files based on build-id's are not found. In newer distro releases you find these at $ ls /usr/lib/debug/.build-id/ 00/ 0d/ 1a/ 25/ 2e/ 3a/ 45/ 4d/ 57/ 64/ 6d/ 77/ 82/ 8b/ 94/ a0/ a9/ b7/ c1/ cd/ d6/ e0/ eb/ f6/ 01/ 0e/ 1b/ 26/ 2f/ 3b/ 46/ 4e/ 58/ 65/ 6e/ 78/ 83/ 8c/ 95/ a1/ ac/ b9/ c4/ ce/ d7/ e1/ ec/ f7/ 02/ 11/ 1c/ 27/ 30/ 3d/ 47/ 50/ 59/ 66/ 6f/ 79/ 84/ 8e/ 96/ a2/ ae/ ba/ c5/ d0/ d8/ e3/ ee/ f9/ 03/ 15/ 1d/ 28/ 32/ 3e/ 48/ 51/ 5b/ 67/ 70/ 7a/ 85/ 8f/ 99/ a3/ b0/ bb/ c6/ d1/ d9/ e4/ ef/ fb/ 05/ 16/ 1e/ 29/ 35/ 41/ 49/ 52/ 5c/ 68/ 72/ 7b/ 87/ 90/ 9a/ a4/ b1/ bc/ c8/ d2/ db/ e5/ f1/ fc/ 08/ 17/ 1f/ 2a/ 36/ 42/ 4a/ 53/ 5e/ 69/ 73/ 7c/ 88/ 91/ 9b/ a5/ b2/ be/ c9/ d3/ dc/ e6/ f2/ fd/ 09/ 18/ 20/ 2b/ 37/ 43/ 4b/ 54/ 60/ 6a/ 75/ 7f/ 89/ 92/ 9c/ a6/ b4/ bf/ cb/ d4/ dd/ e7/ f3/ fe/ 0a/ 19/ 24/ 2d/ 39/ 44/ 4c/ 55/ 61/ 6b/ 76/ 80/ 8a/ 93/ 9f/ a7/ b5/ c0/ cc/ d5/ de/ e8/ f5/ ff/ the first two bytes of the crc make the sub dir name, the debug file name has these first two bytes omitted. $ ls /usr/lib/debug/.build-id/0d c55467dc9eb81a00c7715a790844e7cf035345.debug objdump/objcopy in binutils 2.28 has these lookups properly working. Matthias
Re: [PATCH] fix PR ada/80888
> Ping > If OK, can it be applied please? > (patch applies cleanly to current sources) Patch is OK. I'll apply it when I get a chance. Arno
