[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-04-06 Thread pcarlini at suse dot de
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org |

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-04-06 Thread bkoz at gcc dot gnu dot org
--- Comment #31 from bkoz at gcc dot gnu dot org 2007-04-06 16:38 --- For generic targets, can't you just -errno = 0; +static __thread int errno = 0; on releases of gcc (4.3+) that have the wherewithal to fudge the issue for all systems, even the ones without builtin-TLS? -benjamin

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-04-06 Thread pcarlini at suse dot de
--- Comment #32 from pcarlini at suse dot de 2007-04-06 16:46 --- (In reply to comment #31) For generic targets, can't you just -errno = 0; +static __thread int errno = 0; on releases of gcc (4.3+) that have the wherewithal to fudge the issue for all systems, even the ones

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-04-06 Thread bkoz at gcc dot gnu dot org
--- Comment #33 from bkoz at gcc dot gnu dot org 2007-04-06 17:15 --- Nice idea, but I'm not sure it would work (i'm not very familiar with __thread, etc.): are we sure that with that kind of declaration the strtof co functions themselves automatically use that new improved errno

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-04-06 Thread paolo at gcc dot gnu dot org
--- Comment #34 from paolo at gcc dot gnu dot org 2007-04-07 00:37 --- Subject: Bug 31117 Author: paolo Date: Sat Apr 7 00:36:56 2007 New Revision: 123635 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123635 Log: 2007-04-06 Paolo Carlini [EMAIL PROTECTED] PR

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-04-06 Thread pcarlini at suse dot de
--- Comment #35 from pcarlini at suse dot de 2007-04-07 00:37 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-22 Thread craig dot lawson at centrify dot com
--- Comment #28 from craig dot lawson at centrify dot com 2007-03-22 23:44 --- For HP-UX, SunOS, and Irix: #if !defined(_POSIX_C_SOURCE) # define _POSIX_C_SOURCE 199506L #elif _POSIX_C_SOURCE199506L # error Conflict #endif (why would anyone compile C++ with POSIX

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-22 Thread pcarlini at suse dot de
--- Comment #29 from pcarlini at suse dot de 2007-03-23 00:29 --- Thanks a lot Craig. Touching _POSIX_C_SOURCE makes me a little nervous, in particular if that ends up changing _REENTRANT, as happens on HP-UX. I'd like to ask Dave opinion about it, whether to his best knowledge there is

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-22 Thread dave at hiauly1 dot hia dot nrc dot ca
--- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-23 00:56 --- Subject: Re: c++locale.o thread-unsafe in libstdc++ --- Comment #29 from pcarlini at suse dot de 2007-03-23 00:29 --- Thanks a lot Craig. Touching _POSIX_C_SOURCE makes me a little nervous, in

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread pcarlini at suse dot de
--- Comment #14 from pcarlini at suse dot de 2007-03-15 09:38 --- Thanks Craig for all your additional info, I'll try to make further progress myself over the next days... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread pcarlini at suse dot de
--- Comment #15 from pcarlini at suse dot de 2007-03-15 12:05 --- (In reply to comment #13) Exactly which CPP symbol: On this platform, to select the errno function, /usr/include/errno.h requires defined(_REENTRANT) || defined(_TS_ERRNO) || _POSIX_C_SOURCE - 0 = 199506L

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread craig dot lawson at centrify dot com
--- Comment #16 from craig dot lawson at centrify dot com 2007-03-15 18:15 --- (In reply to comment #15) Tried it. Did not work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread pcarlini at suse dot de
--- Comment #17 from pcarlini at suse dot de 2007-03-15 18:27 --- (In reply to comment #16) Tried it. Did not work. Why? -- pcarlini at suse dot de changed: What|Removed |Added

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread craig dot lawson at centrify dot com
--- Comment #18 from craig dot lawson at centrify dot com 2007-03-15 18:39 --- (In reply to comment #17) Why? Don't know. The file and change were included as expected. Without fully understanding how CPP is evaluating these files, we're shooting in the dark. gcc's -E and -CC

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread pinskia at gcc dot gnu dot org
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-03-15 18:40 --- Try adding -dD which causes the preprocessor to also emit all #defines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread pcarlini at suse dot de
--- Comment #20 from pcarlini at suse dot de 2007-03-15 18:45 --- Thanks Andrew. I'd like to know what happens if you just compile a small snippet like: #define _TS_ERRNO #include cerrno int main() { return errno; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread craig dot lawson at centrify dot com
--- Comment #21 from craig dot lawson at centrify dot com 2007-03-15 19:07 --- (In reply to comment #17) Why? OK, now I know why. Reason is that os_defines.h is included after errno.h. Here's the include sequence: c++locale.cc cerrno /usr/include/errno.h-- extern

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread pcarlini at suse dot de
--- Comment #22 from pcarlini at suse dot de 2007-03-15 19:17 --- (In reply to comment #21) (In reply to comment #17) Why? OK, now I know why. Reason is that os_defines.h is included after errno.h. Oh yes, you are totally right. The problem is that cerrno is one of the very few

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread craig dot lawson at centrify dot com
--- Comment #23 from craig dot lawson at centrify dot com 2007-03-15 19:26 --- (In reply to comment #22) Oh yes, you are totally right. The problem is that cerrno is one of the very few c headers not including bits/c++config.h first. We can easily fix that. Why did cerrno not

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread pcarlini at suse dot de
--- Comment #24 from pcarlini at suse dot de 2007-03-15 19:37 --- (In reply to comment #23) (In reply to comment #22) Oh yes, you are totally right. The problem is that cerrno is one of the very few c headers not including bits/c++config.h first. We can easily fix that.

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread craig dot lawson at centrify dot com
--- Comment #25 from craig dot lawson at centrify dot com 2007-03-15 20:28 --- (In reply to comment #24) Oh, that's excellent news, because we have to include bits/c++config.h first in cerrno anyway... But now you make me curious!!! If you look at c++config.h it doesn't appear do

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread pcarlini at suse dot de
--- Comment #26 from pcarlini at suse dot de 2007-03-15 20:44 --- (In reply to comment #25) Sorry, that news was too excellent. It's not true. Ok. The reason I suggested also including clocale in comment #10 was because I found bits/c++config.h was not enough. I agree that clocale

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-15 Thread craig dot lawson at centrify dot com
--- Comment #27 from craig dot lawson at centrify dot com 2007-03-15 21:17 --- (In reply to comment #26) I understand. I'll collect this information from the systems I have, and then post it here ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-14 Thread craig dot lawson at centrify dot com
--- Comment #10 from craig dot lawson at centrify dot com 2007-03-14 18:13 --- Found it. The problem is that the library is not be ing properly compiled for multi-threaded use, but that by some luck basic_file.cc happened to be compiled that way anyway. c++locale.cc was not so lucky.

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-14 Thread pcarlini at suse dot de
--- Comment #11 from pcarlini at suse dot de 2007-03-15 01:11 --- (In reply to comment #10) The problem is that the library is not be ing properly compiled for multi-threaded use, but that by some luck basic_file.cc happened to be compiled that way anyway. c++locale.cc was not so

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-14 Thread pcarlini at suse dot de
--- Comment #12 from pcarlini at suse dot de 2007-03-15 01:24 --- (In reply to comment #11) Honestly, I don't think that makes sense. Did you *really* test it? Because, as far as I can see, the cc file at issue includes the whole locale, which, in turn, includes bits/c++locale.h,

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-14 Thread craig dot lawson at centrify dot com
--- Comment #13 from craig dot lawson at centrify dot com 2007-03-15 02:02 --- (reply to comment #11) Shear luck: Fair enough. I don't claim to understand it all, either, especially how it came to be this way. What appears to be happening on Solaris 10 is that bits/c++config.h

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-12 Thread craig dot lawson at centrify dot com
--- Comment #4 from craig dot lawson at centrify dot com 2007-03-12 18:26 --- Perhaps there are different degrees of thread safety here. If I write my multi-threaded program such that only one thread does stream I/O with libstdc++, I would expect it to operate safely with respect to

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-12 Thread pcarlini at suse dot de
--- Comment #5 from pcarlini at suse dot de 2007-03-12 18:51 --- (In reply to comment #4) Perhaps there are different degrees of thread safety here. If I write my multi-threaded program such that only one thread does stream I/O with libstdc++, I would expect it to operate safely

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-12 Thread craig dot lawson at centrify dot com
--- Comment #6 from craig dot lawson at centrify dot com 2007-03-12 19:23 --- Anyway, what happens in the GNU systems is that errno is a per-thread variable and the __convert_to_v code has to do nothing special, just safely use it. I agree. The problem is that this is not happening.

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-12 Thread pcarlini at suse dot de
--- Comment #7 from pcarlini at suse dot de 2007-03-12 19:51 --- (In reply to comment #6) Anyway, what happens in the GNU systems is that errno is a per-thread variable and the __convert_to_v code has to do nothing special, just safely use it. I agree. The problem is that this

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-12 Thread craig dot lawson at centrify dot com
--- Comment #8 from craig dot lawson at centrify dot com 2007-03-12 20:07 --- Not on Linux: correct. I could give it a try, but I haven't built this library before. If you could point me to a brief how-to, I could give it a try on a Solaris 10 SPARC. Rather than code around it, I

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-12 Thread pcarlini at suse dot de
--- Comment #9 from pcarlini at suse dot de 2007-03-12 20:14 --- (In reply to comment #8) Not on Linux: correct. Ok. I could give it a try, but I haven't built this library before. If you could point me to a brief how-to, I could give it a try on a Solaris 10 SPARC. Rather than

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-10 Thread pcarlini at suse dot de
--- Comment #3 from pcarlini at suse dot de 2007-03-10 20:46 --- Humm, I'm afraid this is basically a WONTFIX or at least WONTFIX-ANY-TIME-SOON, because we talking about targets using the GENERIC locale model, where, at variance with the GNU locale model, on which we are focused of

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-09 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-10 00:10 --- Sounds like a define is not being added so errno turns into a thread safe version ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117

[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++

2007-03-09 Thread craig dot lawson at centrify dot com
--- Comment #2 from craig dot lawson at centrify dot com 2007-03-10 00:15 --- Seems like that define should come from gcc's -pthread option so it applies to all source files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117