--- Comment #4 from pcarlini at suse dot de 2006-06-23 23:59 ---
Just tested and seems fixed indeed. Thanks a lot!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28138
--- Comment #1 from pcarlini at suse dot de 2006-07-05 21:47 ---
(In reply to comment #0)
> These have data-dependent sizes with no obvious limit, which does not mix well
> with threads and small stacks.
I suppose you are going to provide additional details...
--
--- Comment #4 from pcarlini at suse dot de 2006-07-05 22:32 ---
(In reply to comment #2)
> Sure, here is a test program for versa_string:
Ok, the stack thing is rather straightforward but of course we should first dig
the archives and find when and why, **a lot** of time ago, s
--- Comment #6 from pcarlini at suse dot de 2006-07-05 22:48 ---
(In reply to comment #5)
> The threads point is just a basic stack size issue: threads on linux have a
> fixed size which is often smaller than the main stack size limit.
Ok then.
> With an output width of 6
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
--- Comment #7 from pcarlini at suse dot de 2006-07-05 23:17 ---
Humm, at least the various instances of the problem related to padding seem
simple to fix, by just doing the I/O as part of the padding itself - it's *the
last* stage of the processing anyway...
--
http://gcc.gn
calliing width(0)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org
--- Comment #5 from pcarlini at suse dot de 2006-07-07 17:17 ---
(In reply to comment #4)
> However, we know that it should be possible to write cancel-safe C++
> libraries (including, in particular, libstdc++); otherwise, it's hard to
> use C++ in a multi-threaded applica
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #1 from pcarlini at suse dot de 2006-07-08 21:54 ---
Duplicate of target/28084?!?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28320
--- Comment #18 from pcarlini at suse dot de 2006-07-09 12:45 ---
The problem is confirmed, but nobody knows why the configure-time check for
those wchar facilities succeeds and then the very same functions appear
undefined at build-time. I have no mips-sgi machines available and if the
--- Comment #12 from pcarlini at suse dot de 2006-07-09 17:39 ---
It seemd to me that the best thing to do is adding the include on top of
codecvt_specializations.h itself and removing it from the other places where it
does currently appear (because a grep reveals that the iconv
--- Comment #13 from pcarlini at suse dot de 2006-07-09 17:58 ---
Forgot: those facilities are not always available, therefore we should probably
protect the whole thing with _GLIBCXX_USE_ICONV... I'm adding Benjamin in CC.
--
pcarlini at suse dot de changed:
--- Comment #18 from pcarlini at suse dot de 2006-07-11 12:54 ---
Created an attachment (id=11858)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11858&action=view)
Please test!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
--- Comment #19 from pcarlini at suse dot de 2006-07-11 12:55 ---
Created an attachment (id=11859)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11859&action=view)
... and in case commit!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
--- Comment #20 from pcarlini at suse dot de 2006-07-11 12:56 ---
People affected by the breakage please carefully test the attached and, in
case, commit: I'm going away for a few hours... Thanks!
--
pcarlini at suse dot de changed:
What|Re
--- Comment #3 from pcarlini at suse dot de 2006-07-11 21:55 ---
Humpf, sorry! I will fix it in a moment.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2006-07-11 22:10 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #24 from pcarlini at suse dot de 2006-07-11 22:23 ---
Thanks Rainer and Eric. Then, since we have a workaround in place for the issue
(--disable-wchar_t) and apparently it affects only very old ("broken" as far as
such features are concerned) releases of the OS, I&
--- Comment #23 from pcarlini at suse dot de 2006-07-12 00:21 ---
Thanks Benjamin. FYI, I have just tweaked it back to my original version (if
c++config.h is not included first, _GLIBCXX_USE_ICONV is always found undefined
;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
--- Comment #27 from pcarlini at suse dot de 2006-07-12 12:29 ---
(In reply to comment #26)
> I have 6.5.17 too.
> ... or point out that
> flag in the atchitecture specific page so that other users won't ask.
That makes sense. Can you prepare a patch? Thanks in advance
--- Comment #31 from pcarlini at suse dot de 2006-07-12 16:11 ---
Doc patch committed to mainline and 4_1-branch.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #2 from pcarlini at suse dot de 2005-11-05 09:43 ---
Fixed for 4.1.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from pcarlini at suse dot de 2005-11-06 01:13 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--- Comment #9 from pcarlini at suse dot de 2005-11-06 01:13 ---
Oops...
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24693
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
--- Comment #6 from pcarlini at suse dot de 2005-11-06 13:10 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #2 from pcarlini at suse dot de 2005-11-06 14:13 ---
(In reply to comment #1)
> Maybe the easy way to fix this is just have the distro change their policy of
> compiling with i386 to compile always with i686.
Indeed, that's one point. However, there isn't on
--- Comment #4 from pcarlini at suse dot de 2005-11-06 14:28 ---
(In reply to comment #3)
> Let first point out i486 is more than 15 years old.
Sure, but it's not up to me and you to decide what is on the market, in
embedded form or otherwise. And it's not only abou
--- Comment #4 from pcarlini at suse dot de 2005-11-06 15:58 ---
FWIW, is also "KO" with ICC 9.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
--- Comment #5 from pcarlini at suse dot de 2005-11-06 16:19 ---
Nathan, can you have a look to this PR? (Googling reveals a lot of hits for
nathan & typeid ;) Thanks in advance.
--
pcarlini at suse dot de changed:
What|Removed |A
--- Comment #7 from pcarlini at suse dot de 2005-11-06 17:03 ---
(In reply to comment #6)
> I nearly forgot that I submitted this bug report...
> [...]
At first, I was under the same impression - not a bug - however, I'm not sure
anymore... Have also a look to the A
--- Comment #8 from pcarlini at suse dot de 2005-11-06 17:10 ---
(In reply to comment #7)
> section 2.9.3, and then the last sentence of 2.9.5/7... In your example the
> NTBS addresses (returned by type_info::name()) seem equal...
Sorry, I was wrong! The names, the strings, are
--- Comment #9 from pcarlini at suse dot de 2005-11-06 17:36 ---
Ok, I'm closing this, because the ABI, if not the standard, seems really
unequivocal. About the warning, I don't know, probably it's not that easy
to implement, I also looked for it, but no other compiler
--- Comment #11 from pcarlini at suse dot de 2005-11-06 17:57 ---
Ah, ah, the addresses should be equal in the first place! Ok, thanks for
looking
into this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
--- Comment #6 from pcarlini at suse dot de 2005-11-07 02:49 ---
(In reply to comment #5)
> http://gcc.gnu.org/ml/gcc/2005-11/msg00326.html
>
> In short, you'll never get a completely unified way to implement these
> routines.
Disagree, see: http://gcc.gnu.org/ml/gcc
--- Comment #9 from pcarlini at suse dot de 2005-11-07 10:23 ---
(In reply to comment #8)
> Paolo, the only viable way to get these inlined looks like a libstdc++
> configure-time choice to say --disable-i386-support or sth like that. You
> then
> build libstdc++ agains
--- Comment #2 from pcarlini at suse dot de 2005-11-07 16:59 ---
I have to add a comment: all those crashing KDE applications (I looked at the
KDE PRs) are evidently using mt_allocator. Now, mt_allocator is not the alloc
which FSF gcc4.0.x uses by default, the only one for which ABI
--- Comment #6 from pcarlini at suse dot de 2005-11-07 17:07 ---
(In reply to comment #3)
> I've now verified that even when the entire compiler is compiled with
> --enable-threads=single, the resulting libstdc++ does the full 'lock; xadd'
> thing in __exchang
--- Comment #8 from pcarlini at suse dot de 2005-11-07 17:36 ---
(In reply to comment #7)
> Actually the real issue is not even here and there is no performance problems
> with the out of line/non threaded calls but the real issue is that we are just
> calling them too much.
A
--- Comment #1 from pcarlini at suse dot de 2005-11-07 17:38 ---
.. on the other hand, I think we should close this one, sorry ;) As long as we
have a reference counted string and the user cannot disable the use of atomic
operations when single threaded, there isn't much we c
--- Comment #3 from pcarlini at suse dot de 2005-11-07 17:41 ---
(In reply to comment #2)
> I actually disagree with that. We really need more info (I don't have the
> profiles to see why we are calling this too much but we really need to figure
> it out).
Whatever... ;
--- Comment #2 from pcarlini at suse dot de 2005-11-07 21:54 ---
(In reply to comment #1)
> Note _TREE_H is reserved by the standard for implementations so this is a
> correct use really. Anyone using _TREE_H in their headers are asking for
> troubles as they are using a
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #11 from pcarlini at suse dot de 2005-11-08 10:53 ---
(In reply to comment #10)
> An easy solution might be to check for __gthread_active_p() in
> bits/basic_string before calling __exchange_and_add, and to do this locally
> and
> non-atomically otherwise
--- Comment #10 from pcarlini at suse dot de 2005-11-08 10:58 ---
Ok, apparently short-term at least, "smart" solutions using libgcc and dynamic
linking will not be implemented (one blocker are systems using a static
libgcc.a).
Therefore this one becomes a pure libstdc++-v
--- Comment #12 from pcarlini at suse dot de 2005-11-08 11:30 ---
In my opinion, the way to go is consistently using the macro __GTHREADS which
is undefined when --enable-threads=single is passed. This is consistent with
the approach already used in mt_allocator, for instance. And
--- Comment #14 from pcarlini at suse dot de 2005-11-08 11:50 ---
(In reply to comment #13)
> Indeed, other parts of libstdc++ already rely on __gthread_active_p().
Sure, see mt_alloc: there is an external __GTHREADS and an internal
__gthread_active_p().
> Using __GTHREADS wou
--- Comment #16 from pcarlini at suse dot de 2005-11-08 12:06 ---
(In reply to comment #15)
> How about we make (or I contribute) a set of 'atomic-if-needed'
> 'exchange-and-add' and 'add' inlineable functions?
>
> These could just replace _
--- Comment #11 from pcarlini at suse dot de 2005-11-08 13:37 ---
Changing the declarations in include/bits/atomicity.h to inline definitions
forwarding to the builtins and including instead of
in config/cpu/*/atomicity.h for the supported arch families
would be most of it, probably
--- Comment #18 from pcarlini at suse dot de 2005-11-08 14:34 ---
(In reply to comment #17)
> > To repeat: this is needed anyway, because we want to use consistently the
> > --thread-model configure option. Nothing will go in not checking also and
> > exploting the
--- Comment #19 from pcarlini at suse dot de 2005-11-08 14:54 ---
(In reply to comment #18)
> Sure, this is the general idea. I'm a little bit concerned that for something
> apparently so elemental as an addiction (atomic, yes...) we are going to add
> a conditional, but p
--- Comment #4 from pcarlini at suse dot de 2005-11-08 21:48 ---
(In reply to comment #3)
> Does your comment mean that this configuration is strongly discouraged, or
> that the bug report lacked relevant information?
Neither ;) Not the former, because we are putting a lot of e
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
--- Comment #1 from pcarlini at suse dot de 2005-11-09 17:00 ---
(In reply to comment #0)
> Those tests *never* fail in 4_0-branch, which doesn't use the builtins, and
> never did in mainline before the below of mine (and a simultaneous one to
> the compiler, which emptie
--- Comment #3 from pcarlini at suse dot de 2005-11-09 17:45 ---
(In reply to comment #2)
> Hmm you said in:
> http://gcc.gnu.org/ml/libstdc++/2005-11/msg00149.html
>
> That was really a glibc bug.
Exactly *was*. Ehi, do you think I'm stupid? Of course in the meanwhi
--- Comment #4 from pcarlini at suse dot de 2005-11-09 17:51 ---
(In reply to comment #3)
> .Alternately, the ia64 builtins
> themselves can be defective, but that seems much less likely to me, because
> we are talking about a very c
--- Comment #2 from pcarlini at suse dot de 2005-11-09 17:52 ---
Your are welcome!
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #5 from pcarlini at suse dot de 2005-11-09 19:30 ---
Some additional details from testresults: the bulk of the builtin atomics
changes
went in around mid of April, the ia64 specific bits, on April, 14. All the
results that Andreas sent at the beginning of the month (for
--- Comment #4 from pcarlini at suse dot de 2005-11-10 01:12 ---
(In reply to comment #3)
> We could leave _M_get_deleter private...
This would be nice, of course. Can you test the patch? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24595
--- Comment #6 from pcarlini at suse dot de 2005-11-10 01:41 ---
Actually, I'm pretty much worried by this issue: whatever is at fault, as a
matter of fact, for this target the library testsuite shows a severe
misbehavior
in a MT environment. Raising the priority/severity see
--- Comment #7 from pcarlini at suse dot de 2005-11-10 09:59 ---
I'm marking this as a 4.1 Regression: certainly it is. If people can figure a
way to workaround it at the library level, I'm ok with that.
--
pcarlini at suse dot de changed:
What
--- Comment #1 from pcarlini at suse dot de 2005-11-11 16:16 ---
Confirmed, thanks a lot!
--
pcarlini at suse dot de changed:
What|Removed |Added
Status
--- Comment #1 from pcarlini at suse dot de 2005-11-11 16:44 ---
Can you please attach a simple testcase? Thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #1 from pcarlini at suse dot de 2005-11-11 17:30 ---
Confirmed, thanks!
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from pcarlini at suse dot de 2005-11-11 19:02 ---
Ok ;) Thanks!
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.0.3
Version|3.0.2 |4.0.2
http
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24805
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #3 from pcarlini at suse dot de 2005-11-12 11:27 ---
(In reply to comment #2)
> As for the original bug report: it's easy to verify by inspecting the source
> that _Mem_fn has no base class as required.
I beg to disagree. Have you really checked the actual ver
--- Comment #1 from pcarlini at suse dot de 2005-11-12 12:45 ---
Doug, can you look a bit into this one too? Thanks!
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2005-11-12 13:27 ---
Hi Doug. First thing to do, before actually studying your extremely useful and
detailed reply (THANKS), is adding Howard in CC...
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #2 from pcarlini at suse dot de 2005-11-12 13:33 ---
Thanks a lot. I will take care of applying the patch asap.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2005-11-13 04:25 ---
Agreed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|WAITING
--- Comment #6 from pcarlini at suse dot de 2005-11-13 04:34 ---
Ok, therefore suspended (not really invalid, not really open) seems to me an
appropriate status. Otherwise, a mildly "depressing" remark: I'm pretty sure
some people are not very happy with pragmas. I'
--- Comment #7 from pcarlini at suse dot de 2005-11-13 04:35 ---
Ok, let's suspend it, for now.
--
pcarlini at suse dot de changed:
What|Removed |
--- Comment #6 from pcarlini at suse dot de 2005-11-13 12:20 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pcarlini at suse dot de 2005-11-13 12:21 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pcarlini at suse dot de 2005-11-13 12:21 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pcarlini at suse dot de 2005-11-13 12:22 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pcarlini at suse dot de 2005-11-15 00:31 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #3 from pcarlini at suse dot de 2005-11-15 12:02 ---
> 2- Otherwise, a lock in _M_reclaim_block only when __block->_M_thread_id !=
>__thread_id. At the same time has to be changed _M_reserve_block too,
>however, and it's tricky to do that without
--- Comment #5 from pcarlini at suse dot de 2005-11-15 12:31 ---
(In reply to comment #4)
> Unfortunately I cannot perform such test because it would require changing
> stdlibc++ on many machines.
Out of curiosity: why many and not just one (and optionally, of course, alo
--- Comment #11 from pcarlini at suse dot de 2005-11-15 16:39 ---
(In reply to comment #10)
> And my comment in #6 still holds for this bug. I think libstdc++ should
> rethink about this.
libstdc++ can rething anything, in principle, but if you change the component
to l
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24881
[meta-bug] Non-refcounted, moveable basic_string
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at sus
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882
--- Comment #5 from pcarlini at suse dot de 2005-11-15 21:07 ---
This PR can now be closed, basing on up to date comments from John David Anglin
([EMAIL PROTECTED]), which indicate that now shared versions of libgcc
are
built on both 32 and 64-bit ports. He also remarks that "
--- Comment #18 from pcarlini at suse dot de 2005-11-15 22:00 ---
(In reply to comment #16)
> Here is the current patch so for libstdc++ (I did not test it yet):
Before patching this and that in the runtime library, don't you believe that:
1- If, as Mark said, (__imag__ t) is a
--- Comment #20 from pcarlini at suse dot de 2005-11-15 22:16 ---
About the optimization issue, maybe we should file a separate enhancement PR,
if there isn't already one. Really, we should be able to optimize well any
variant of this kind of code.
--
http://gcc.gnu.org/bug
--- Comment #10 from pcarlini at suse dot de 2005-11-15 22:38 ---
To be sure we don't confuse two issues here (see also my #7), all the
containers
are already able to use shared memory allocators such as libmm:
http://www.ossp.org/pkg/lib/mm/
(via a very lightweight wrapper).
--- Comment #8 from pcarlini at suse dot de 2005-11-17 13:50 ---
I have got additional evidence that __sync_fetch_and_add does not work
correctly. If, for example, in this code, stressed in the testcase
12658_thread-1.cc, and using atomic operations:
const locale&
lo
--- Comment #10 from pcarlini at suse dot de 2005-11-18 15:23 ---
(In reply to comment #9)
> I should note that
> ld.acq+cmpxchg.rel is a full barrier.
> as noted in ia64.c so a mf is not required.
Did you read the last message from Alexander on the libstdc++ mailing
101 - 200 of 2287 matches
Mail list logo
