Re: [C++ PATCH] Optimize C++ comdat ctors/dtors in classes without virtual bases (PR c++/3187, take 3)

On Mon, Nov 30, 2009 at 10:46:31PM -0500, Jason Merrill wrote:
> On 11/30/2009 05:36 PM, Jakub Jelinek wrote:
> >	* config/abi/pre/gnu.ver: Don't export certain base dtors that
> >	weren't previously exported.
> 
> Is this necessary?  I thought it was OK to add new exported symbols, but 
> you'd know better than I.

Yes.  We definitely must not export them with the old symbol versions where
they have not been exported before (GLIBCXX_3.4 and GLIBCXX_3.4.10).
We could export them at  <at>  <at> GLIBCXX_3.4.14 (which would mean the same gnu.ver
changes and mentioning the D2 symbols in GLIBCXX_3.4.14 section), but that
has a problem that we only emit those D2 symbols when HAVE_COMDAT_GROUP, so
in !HAVE_COMDAT_GROUP configurations the exported list would be different.
I have no idea how to force generation of those symbols otherwise so that
they are exported on all targets.

> 
> >+	  && (SUPPORTS_ONE_ONLY || !DECL_WEAK (fns[0]))
> 
> This test seems unnecessary; I don't see the problem with using aliases 
> on targets with weak symbols but no one-only support.

This is to fix AIX (and is actually unrelated to this patch, it can be dealt
with separately).  In theory it should work well, but David Edelsohn
reported that some symbols were missing from libstdc++.so without it.  I
have no access to AIX and have no idea what AIX linker is doing with the
symbols.  !SUPPORTS_ONE_ONLY targets don't have DECL_ONE_ONLY, but instead
just use DECL_WEAK symbols, so I thought when we don't do this optimization
on !HAVE_COMDAT_GROUP SUPPORTS_ONE_ONLY targets for comdat and comdat-like

Committed: Fix ext/profile/mutex_extensions.cc regression

In r154852:154860, there was a change shifting the
libstdc++-v3/include/bits/c++config line-numbers, causing this
test to fail since then on all platforms; see gcc-testresults <at> .
I'm not sure how regression was missed in testing (other than
perhaps a missing run on a _GLIBCXX_HAVE_ATTRIBUTE_VISIBILITY
platform), but either way, the trivial fix just committed was:

libstdc++-v3:
	* testsuite/ext/profile/mutex_extensions.cc: Adjust dg-error line
	number.

Index: testsuite/ext/profile/mutex_extensions.cc
===================================================================
--- testsuite/ext/profile/mutex_extensions.cc	(revision 154935)
+++ testsuite/ext/profile/mutex_extensions.cc	(working copy)
 <at>  <at>  -22,5 +22,5  <at>  <at> 

 #include <vector>

-// { dg-error "Cannot use -D_GLIBCXX_PROFILE with " "" { target *-*-* } 165 }
+// { dg-error "Cannot use -D_GLIBCXX_PROFILE with " "" { target *-*-* } 167 }
 // { dg-excess-errors "In file included from" }

brgds, H-P

[v3] Add some std::bind tests

Hi,

checked x86-64-linux, committed to mainline.

Paolo.

////////////////////

2009-12-03  Paolo Carlini  <paolo.carlini <at> oracle.com>

	* testsuite/20_util/bind/ref.cc: Add.
	* testsuite/20_util/bind/all_bound.cc: Likewise.
	* testsuite/20_util/bind/nested.cc: Likewise.
	* testsuite/20_util/bind/placeholders.cc: Likewise.

Index: testsuite/20_util/bind/ref.cc
===================================================================
--- testsuite/20_util/bind/ref.cc	(revision 0)
+++ testsuite/20_util/bind/ref.cc	(revision 0)
 <at>  <at>  -0,0 +1,55  <at>  <at> 
+// { dg-options "-std=gnu++0x" }
+// Copyright (C) 2009 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.

[FYI] ChangeLogs cleaned-up a bit

Hi,

in my HJ Lu-ish mood, I removed quite a few spurious white spaces and
tabs lurking in our ChangeLogs files, actually quite annoying in a new
emacs setup I'm using now (they are all displayed bright red)...

Paolo.

Re: [FYI] ChangeLogs cleaned-up a bit

> in my HJ Lu-ish mood, I removed quite a few spurious white spaces and
> tabs lurking in our ChangeLogs files, actually quite annoying in a new
> emacs setup I'm using now (they are all displayed bright red)...

Thanks, had been tempted myself. It is now very distracting!

-benjamin

[profile-stdlib] PATCH: Add three diagnostics and implement cost factor parameterization

Hello libstdc++ maintainers,

The attached patch implements the following in the profile-stdlib branch:
1) New diagnostics
  - list-to-vector; if data is inserted at the end of the list and
iteration operation is common, vector is better.
  - list-to-slist; slist is more likely to fit in a cache line due to
less memory usage.
  - list-to-set; if a find operation, 'std::find', is frequently used
in the list, set is better.
2) Cost factor parameterization; constant factors of the cost models
for diagnostics can be read from a file, "libstdcxx-profile.conf" or
environment variables.

There is an issue related to thel instrumentation of 'std::find'.
It seems that 'bits/stl_algo.h' was modified for the parallel mode so
that its functions declared in the namespace of '_GLIBCXX_STD_P' can
be used instead of original functions in the release mode.
Currently, I did the same thing, conditional compilation stuff, to
hide the original 'find' function under its wrapper function.

This inevitably causes a modification to the original 'bits/stl_algo.h'.
Alternatively, it is possible to duplicate the 'bits/stl_algo.h' in
'profile/stl_algo.h' and modify the copy to avoid any intrusion from
the profile mode to the release mode.
It would be appreciated if you come up with a better idea to deal with this.

Thank you,
Changhee

Re: [profile-stdlib] PATCH: Add three diagnostics and implement cost factor parameterization

Hi Changee,

Some initial comments, I'll take another look later.

I noticed a few formatting issues in
libstdc++-v3/include/profile/iterator_tracker.h - overlong lines, and
"public:" indented incorrectly.

The doxygen comment for profile/algorithm says:
/**  <at> file parallel/algorithm

This include guard is not in the correct format:
#ifndef PROFCXX_PROFILER_LIST_TO_SLIST_H
That could clash with a user header (I don't like the format used by
the other profile headers, with two trailing underscores, but that
seems to be the form used consistently.)

This is wrong:
+#ifdef __GXX_EXPERIMENTAL_CXX0X__
+      swap(vector&& __x)
+#else
       swap(vector& __x)
+#endif

vector::swap() does not work with rvalues now, the same goes for

+#ifdef __GXX_EXPERIMENTAL_CXX0X__
+  template<typename _Tp, typename _Alloc>
+    inline void
+    swap(vector<_Tp, _Alloc>&& __lhs, vector<_Tp, _Alloc>& __rhs)

Re: [profile-stdlib] PATCH: Add three diagnostics and implement cost factor parameterization

On Sun, Dec 6, 2009 at 7:38 PM, Changhee Jung <haemil99 <at> gmail.com> wrote:
> Hello libstdc++ maintainers,
>

Hello maintainers,

Can this still make it to 4.5, given that it affects only the profile
mode?  If so, could you review it as a patch to trunk instead of
branch?  There are no other changes on the profile-stdlib branch since
the last merge to trunk, except for very minor fixes.

Thank you,
Silvius

> The attached patch implements the following in the profile-stdlib branch:
> 1) New diagnostics
>  - list-to-vector; if data is inserted at the end of the list and
> iteration operation is common, vector is better.
>  - list-to-slist; slist is more likely to fit in a cache line due to
> less memory usage.
>  - list-to-set; if a find operation, 'std::find', is frequently used
> in the list, set is better.
> 2) Cost factor parameterization; constant factors of the cost models
> for diagnostics can be read from a file, "libstdcxx-profile.conf" or
> environment variables.
>
> There is an issue related to thel instrumentation of 'std::find'.
> It seems that 'bits/stl_algo.h' was modified for the parallel mode so
> that its functions declared in the namespace of '_GLIBCXX_STD_P' can
> be used instead of original functions in the release mode.

Re: Bug in GCC 4.5 c++0x version of std::list<T>::merge(&&)?

2009/12/8 Benjamin Redelings I:
> Hi,

Hi,
I've CC'd the libstdc++ list, please reply there instead of the gcc list.

> It seems that many current uses of list<T>::merge( ) fail to compile with
> -std=c++0x, but I don't see a bug in bugzilla for this.  Itseems to result
> from:
>
> list<_Tp, _Alloc>::
> #ifdef __GXX_EXPERIMENTAL_CXX0X__
> merge(list&& __x)
> #else
> merge(list& __x)
> #endif
>
> For c++0x, don't we need BOTH versions, since lvalues no longer bind to
> rvalue references, or am I missing something?

The WP only has:
void merge(list<T,Allocator>&& x);
template <class Compare> void merge(list<T,Allocator>&& x, Compare comp);

See http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1133
which covers a similar issue with splice.

Jonathan

Re: Bug in GCC 4.5 c++0x version of std::list<T>::merge(&&)?

2009/12/8 Jonathan Wakely:
> 2009/12/8 Benjamin Redelings I:
>> Hi,
>
> Hi,
> I've CC'd the libstdc++ list, please reply there instead of the gcc list.
>
>> It seems that many current uses of list<T>::merge( ) fail to compile with
>> -std=c++0x, but I don't see a bug in bugzilla for this.  Itseems to result
>> from:
>>
>> list<_Tp, _Alloc>::
>> #ifdef __GXX_EXPERIMENTAL_CXX0X__
>> merge(list&& __x)
>> #else
>> merge(list& __x)
>> #endif
>>
>> For c++0x, don't we need BOTH versions, since lvalues no longer bind to
>> rvalue references, or am I missing something?
>
> The WP only has:
> void merge(list<T,Allocator>&& x);
> template <class Compare> void merge(list<T,Allocator>&& x, Compare comp);
>
> See http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1133
> which covers a similar issue with splice.

I've requested that overloads of list::merge be added as well, watch
that issue to see the outcome.