[Bug libstdc++/50703] std::stringstream not thread-safe

2015-12-11 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #9 from Jonathan Wakely  ---
No testcase or results for supported releases provided, closing.

[Bug libstdc++/50703] std::stringstream not thread-safe

2013-08-04 Thread liuxiaopi349 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703

peter liuxiaopi349 at hotmail dot com changed:

   What|Removed |Added

 CC||liuxiaopi349 at hotmail dot com

--- Comment #8 from peter liuxiaopi349 at hotmail dot com ---
Hi, Hoenle2007, 
Do you have any update on this?
Encountering a probably similar case on ostringstream (not 100% sure). It is in
Centos Linux in x86_64 platform with older stdlib like 4.1.   Just want to know
what is final conclusion on the thread safty of stringstream/ostringstream as
the case you mentioned in this post.

Regards,


(In reply to Hoenle2007 from comment #7)
 @Jonathan: You ask was gcc built with a non-default value for
 --enable-clocale ?. I don't think so. We perform cross development on
 Windows with MinGW as supported out-of-the-box by the RTEMS operating system
 distribution. With that distribution the cross compilation tools come
 already pre-compiled. Maybe the following gcc output helps:
 
 $ sparc-rtems-gcc -v
 Reading specs from
 c:/opt/rtems-4.8-mingw/bin/../lib/gcc/sparc-rtems/4.2.4/specs
 Target: sparc-rtems
 Configured with: ../gcc-4.2.4/configure --target=sparc-rtems --host
 i686-mingw32 --build i486-slackware-linux --with-gnu-as --with-gnu-ld
 --with-newlib --verbose --enable-threads --enable-languages=c,c++
 --disable-nls --prefix=/opt/rtems-4.8-mingw
 --enable-version-specific-runtime-libs --with-system-zlib
 --disable-libstdcxx-pch --disable-win32-registry --without-included-gettext
 Thread model: rtems
 gcc version 4.2.4
 
 -
 
 @Paolo: We never access a std::stringstream object from different threads
 but always from a single thread. When we share objects between threads, we
 protect them by a pthread mutex. I will perform a test with a new
 GCC/libstdc++ probably mid November. In case the problem persists I will try
 to set up a short, self contained reproducer.
 
 -
 
 Regards
 Alfred


[Bug libstdc++/50703] std::stringstream not thread-safe

2011-10-17 Thread hoenle2...@kayser-threde.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703

--- Comment #7 from hoenle2...@kayser-threde.com 2011-10-17 08:17:21 UTC ---
@Jonathan: You ask was gcc built with a non-default value for --enable-clocale
?. I don't think so. We perform cross development on Windows with MinGW as
supported out-of-the-box by the RTEMS operating system distribution. With that
distribution the cross compilation tools come already pre-compiled. Maybe the
following gcc output helps:

$ sparc-rtems-gcc -v
Reading specs from
c:/opt/rtems-4.8-mingw/bin/../lib/gcc/sparc-rtems/4.2.4/specs
Target: sparc-rtems
Configured with: ../gcc-4.2.4/configure --target=sparc-rtems --host
i686-mingw32 --build i486-slackware-linux --with-gnu-as --with-gnu-ld
--with-newlib --verbose --enable-threads --enable-languages=c,c++ --disable-nls
--prefix=/opt/rtems-4.8-mingw --enable-version-specific-runtime-libs
--with-system-zlib --disable-libstdcxx-pch --disable-win32-registry
--without-included-gettext
Thread model: rtems
gcc version 4.2.4

-

@Paolo: We never access a std::stringstream object from different threads but
always from a single thread. When we share objects between threads, we protect
them by a pthread mutex. I will perform a test with a new GCC/libstdc++
probably mid November. In case the problem persists I will try to set up a
short, self contained reproducer.

-

Regards
Alfred


[Bug libstdc++/50703] std::stringstream not thread-safe

2011-10-13 Thread hoenle2...@kayser-threde.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703

--- Comment #3 from hoenle2...@kayser-threde.com 2011-10-13 07:56:47 UTC ---
I will try libstdc++ 4.6.x or 4.5.x. Question: May I use this new library with
the relatively old compiler I am currently utilizing or do I need to upgrade to
a newer compiler version also?


[Bug libstdc++/50703] std::stringstream not thread-safe

2011-10-13 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703

--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-13 
08:11:42 UTC ---
You cannot use libstdc++ separately from the GCC version it ships with, so to
use libstdc++ 4.6.1 you must use G++ 4.6.1


[Bug libstdc++/50703] std::stringstream not thread-safe

2011-10-13 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703

--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-13 
12:01:56 UTC ---
was gcc built with a non-default value for --enable-clocale ?

what locale is being used by the application?


[Bug libstdc++/50703] std::stringstream not thread-safe

2011-10-13 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703

--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-13 
12:22:45 UTC ---
Note that in case problems persist, a testcase is *required* for anything
concrete to happen. It's impossible to diagnose in any serious detail
thread-safety issues without knowing the code, trying it's just a huge waste of
time, we know that. Also note, just in case isn't already obvious, that C++98
doesn't talk about threads *at all*, thus very little is guaranteed in a
non-implementation defined way.


[Bug libstdc++/50703] std::stringstream not thread-safe

2011-10-12 Thread hoenle2...@kayser-threde.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703

--- Comment #1 from hoenle2...@kayser-threde.com 2011-10-12 15:36:50 UTC ---
Created attachment 25475
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25475
debugger screenshot


[Bug libstdc++/50703] std::stringstream not thread-safe

2011-10-12 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-10-12
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-12 
15:39:32 UTC ---
First, 4.2.x is very old and not maintained anymore. Thus, before anything
else, please try 4.6.x or 4.5.x. Then, before taking any action, we need a
short, self contained reproducer (as specified in the bug reporting
instructions).