more verbosity in libstdc++ configure

I noticed that there were a few places in the libstdc++ configury that
make tests but don't print out the results; this improves them.

Tested by building libstdc++ native on powerpc-darwin and cross to
i686-darwin.

-- 
- Geoffrey Keating <geoffk <at> apple.com>

===File ~/patches/libstdc++-configstatusmessages.patch======
2005-08-03  Geoffrey Keating  <geoffk <at> apple.com>

	* acinclude.m4 (GLIBCXX_CHECK_SETRLIMIT_ancilliary): Print
	status messages.
	(GLIBCXX_CHECK_S_ISREG_OR_S_IFREG): Likewise.
	(GLIBCXX_CHECK_POLL): Likewise.
	(GLIBCXX_CHECK_WRITEV): Likewise.
	(GLIBCXX_CHECK_INT64_T): Likewise.
	(GLIBCXX_CHECK_LFS): Likewise.
	* configure: Regenerate.

Index: acinclude.m4
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/acinclude.m4,v
retrieving revision 1.321
diff -u -p -u -p -r1.321 acinclude.m4
--- acinclude.m4	27 Jul 2005 18:27:56 -0000	1.321
+++ acinclude.m4	3 Aug 2005 18:40:52 -0000
 <at>  <at>  -333,6 +333,7  <at>  <at>  dnl  _GLIBCXX_RES_LIMITS if we can set a

Better darwin cross support

This makes the libstdc++ configury behave like GCC's configury:
crosses between darwin architectures don't really count as crosses.

The reason for this is that although crossconfig.m4 is a solution, it
gets out-of-date quickly (I noticed particularly the int64_t test) and
it's hard to keep track of all the things that matter; so it's a lot
easier to just have autoconf do its thing.

I also noticed that the testsuite behaviour changed radically when
I put in the export control.  That's very undesirable, so let's not do
that: more tests all the time!

Tested by building a cross libstdc++ from powerpc-darwin to i686-darwin.

--

-- 
- Geoffrey Keating <geoffk <at> apple.com>

===File ~/patches/libstdc++-darwin-crosses.patch============
2005-08-03  Geoffrey Keating  <geoffk <at> apple.com>

	* configure.ac: Don't use GCC_NO_EXECUTABLES or clear
	GLIBCXX_IS_NATIVE on Darwin crosses.
	* acinclude.m4 (GLIBCXX_CONFIGURE_TESTSUITE): Don't skip configuring
	the testsuite just because there's no symbol versioning.

Index: configure.ac
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/configure.ac,v
retrieving revision 1.38

PATCH ping: silence warning in eh_call.cc

Ping?

  http://gcc.gnu.org/ml/libstdc++/2005-07/msg00037.html

Ben

Re: PATCH: LDFLAGS handling in V3

Alexandre Oliva wrote:
> On Jul 28, 2005, Mark Mitchell <mark <at> codesourcery.com> wrote:
>
> Yep, this should work.  It won't make LTLDFLAGS overridable by users,
> but I'm not even sure this is desirable.

Alexandre --

Did you get a chance to look at

http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01945.html

?

Thanks,

--

-- 
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com
(916) 791-8304

[committed] xfail, 26_numerics/cmath/c99_classification_macros_c.cc on darwin

Since this is not really a regression and only really the test really 
started to
test correctly on darwin, I decided just to xfail it the test; just 
like on GNU/Linux.

Committed as obvious to the mainline after testing it worked.

Thanks,
Andrew Pinski

ChangeLog;

	* testsuite/26_numerics/cmath/c99_classification_macros_c.cc:
	xfail on *-*-darwin*.

Index: testsuite/26_numerics/cmath/c99_classification_macros_c.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c.cc,v
retrieving revision 1.2
diff -u -p -r1.2 c99_classification_macros_c.cc
--- testsuite/26_numerics/cmath/c99_classification_macros_c.cc	2 Mar 2005 03:02:45 -0000	1.2
+++ testsuite/26_numerics/cmath/c99_classification_macros_c.cc	9 Aug 2005 16:52:49 -0000
 <at>  <at>  -27,8 +27,8  <at>  <at> 
 // invalidate any other reasons why the executable file might be covered by
 // the GNU General Public License.

-// { dg-do compile { xfail *-*-linux-gnu } }
-// { dg-excess-errors "" { target *-*-linux-gnu } }

[patch] : Adding move symantics to vector

Here is a patch which makes vector rvalref-aware, so it never performs
unnessasary copies of things internally when it is shifting around things.

I haven't added any more of the user-visable changes (function which
allow you to push_back an rvalref, etc), espically due to recent
problems with the constructors.

The major final thing I haven't added (and the reason I've been quiet
for a while) is that I've been having great problems implementing move
semantics on stable_sort and stable_partition without either moveable
types or trivial types (like int) being sub-optimal, or the code
bloating. I hope to crack this soon :)

I also now consider that all the "basic framework" and most of the speed
improvement of templated-based rvalue references are present. However it
looks like it might be too late now for 4.1?

This patch has been bootstrapped on powerpc-apple-darwin8.2.0 and x86 linux.

Binary files libstdc++-v3.so_7.clean/include/.DS_Store and libstdc++-v3/include/.DS_Store differ
diff -urNx '*CVS*' libstdc++-v3.so_7.clean/include/bits/stl_construct.h libstdc++-v3/include/bits/stl_construct.h
--- libstdc++-v3.so_7.clean/include/bits/stl_construct.h	2005-07-05 08:46:01.000000000 +0100
+++ libstdc++-v3/include/bits/stl_construct.h	2005-08-08 21:03:13.000000000 +0100
 <at>  <at>  -98,6 +98,29  <at>  <at> 

   /**
    *  <at> if maint
+   * Should move construct an object in existing memory by invoking the

Why not optimize _Destroy for non-standard allocators, too?

In stl_construct.h in gcc 4.1, _Destroy puts extra effort to check that
the standard allocator is used before optimizing for types that have
trivial destructors.

This behavior is described by the code comment:
   * Destroy a range of objects using the supplied allocator.  For
   * nondefault allocators we do not optimize away invocation of
   * destroy() even if _Tp has a trivial destructor.

In a benchmark that uses a custom allocator that reflects a large
application, we found over a 1% improvement after allowing the same
optimization for non-default allocators. For us, this speedup comes from
faster calls to vector::clear().

What's the intention for not optimizing this function for non-default
allocators?

Regards,

Thomas Kho

Re: Why not optimize _Destroy for non-standard allocators, too?

KHO,THOMAS WIN wrote:

>In stl_construct.h in gcc 4.1, _Destroy puts extra effort to check that
>the standard allocator is used before optimizing for types that have
>trivial destructors.
>
>This behavior is described by the code comment:
>   * Destroy a range of objects using the supplied allocator.  For
>   * nondefault allocators we do not optimize away invocation of
>   * destroy() even if _Tp has a trivial destructor.
>
>In a benchmark that uses a custom allocator that reflects a large
>application, we found over a 1% improvement after allowing the same
>optimization for non-default allocators. For us, this speedup comes from
>faster calls to vector::clear().
>
>What's the intention for not optimizing this function for non-default
>allocators?
>
>  
>
The short answer is I don't think we can. We assume that for
std::allocator we that allocator.destroy and allocator.construct just
call placement new and operator delete, and for basic types we don't
have to call them at all. A general allocator could in theory do
whatever it likes in these functions and we can't just ignore that

I have a basic implementation on my computer of adding a new class
called trivial_allocator<T>, which can be overloaded for both the
allocators in the library and user's own allocators which says we can

Update FSF address [committed]

Long boring, bzipped patch attached.

[PATCH] PR23358 Remove unused template parameter in _Destroy

The extra template parameter causes specialization to be ignored.

Regards,

Thomas Kho

ChangeLog:
2005-08-18  Thomas Kho  <tkho <at> ucla.edu>
	PR libstdc++/23358
	* stl_construct.h (_Destroy): Removed unused template parameter.