[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-11 Thread pcarlini at suse dot de
--- Additional Comments From pcarlini at suse dot de 2004-10-11 17:26 --- Created an attachment (id=7327) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7327&action=view) Valgrind (2.2, --tool=memcheck) output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-11 Thread pcarlini at suse dot de
--- Additional Comments From pcarlini at suse dot de 2004-10-11 17:38 --- Forgot to add: to reproduce, remember to provide --enable-__cxa_atexit at build time! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-11 Thread bkoz at gcc dot gnu dot org
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-10-11 22:51 --- It would be list ugh. Damn that allocator rebinding! I'm developing severe issues with this particular container. Well, this kills off this QoI improvement. I've reverted this on mainline, and fixed up the

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-11 Thread bkoz at gcc dot gnu dot org
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-10-11 22:52 --- Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-11 Thread pcarlini at suse dot de
--- Additional Comments From pcarlini at suse dot de 2004-10-11 23:50 --- > It would be list ugh. Damn that allocator rebinding! I'm developing severe > issues with this particular container. Well, this kills off this QoI > improvement. I've reverted this on mainline, and fixed up the

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-11 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2004-10-12 00:30 --- Subject: Re: Critical ~__pool troubles >Ok, but as long as we don't use that, let's avoid taking the lock a second >time in _M_reserve_block, the new calls and so on... I propose to protect >with macros or #if 0 o

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-11 Thread cvs-commit at gcc dot gnu dot org
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-12 01:10 --- Subject: Bug 17937 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-12 01:10:39 Modified files: libstdc++-v3 : ChangeLog acconfig.h acinclude.m4 con

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-12 Thread pcarlini at suse dot de
--- Additional Comments From pcarlini at suse dot de 2004-10-12 08:27 --- > However, please give me a bit to finish this stuff up! I'll check in a > fix for this immediate problem, and then please give me a bit of time to > do a round of performance analysis. I'll ping you when I'm done,

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-12 Thread pcarlini at suse dot de
--- Additional Comments From pcarlini at suse dot de 2004-10-12 08:53 --- Sorry, actually I meant around 25%, rather troublesome, anyway... Frankly, I don't know where the slowdown comes from, we should profile the testcase for both the allocators. These are some numbers on my P4-2400: mt

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-12 Thread bkoz at gcc dot gnu dot org
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-10-12 15:50 --- Yep I'll add this to my other tests (insert-thread) to profile today, thanks for the pointer. Can I close this out? I believe this is fixed, no? -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?i

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-12 Thread pcarlini at suse dot de
--- Additional Comments From pcarlini at suse dot de 2004-10-12 15:54 --- Yes, can only be ok, now! ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-12 Thread bkoz at gcc dot gnu dot org
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-10-13 02:56 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-13 Thread matz at suse dot de
--- Additional Comments From matz at suse dot de 2004-10-13 18:28 --- Still doesn't fully work. The initial testcase now works, but aRts still segfaults. This time I need this testcase: - #include std::string idl_filename; extern std::string idl

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-13 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 18:33 --- I think that is a bug in the front-end: :; if (__priority == 65535) goto ; else goto ; :; if (__initialize_p == 0) goto ; else goto ; :; __comp_dtor (&idl_filename); :; if (__priority == 65535) go

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-13 Thread matz at suse dot de
--- Additional Comments From matz at suse dot de 2004-10-13 18:37 --- Ah, the problem is, that for some reasons GCC emits _two_ dtor functions for 'idl_filename' (__tcf_2 and __tcf_1), but only if the extern decl comes after the definition. Okay, this is an error in itself, but it seem

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-13 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 18:39 --- I filed the c++ front-end bug under PR 17976 with a simple example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-13 Thread matz at suse dot de
--- Additional Comments From matz at suse dot de 2004-10-13 18:41 --- Oh, wire-crossing. I filed this now as PR17977. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-13 Thread matz at suse dot de
--- Additional Comments From matz at suse dot de 2004-10-13 18:42 --- Argh. Don't ask people to do stuff, if you are doing it yourself ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-15 Thread pinskia at gcc dot gnu dot org
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937