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

Reply via email to