Bug 14902 - Stream checking functions fail when -pthread option is used.
Summary: Stream checking functions fail when -pthread option is used.
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.3.3
: P2 normal
Target Milestone: 3.4.1
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2004-04-09 20:19 UTC by Kevin Harris
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: powerpc-ibm-aix5.1.0.0
Target: powerpc-ibm-aix5.1.0.0
Build: powerpc-ibm-aix5.1.0.0
Known to work:
Known to fail:
Last reconfirmed:

Preprocessed source when -pthread is used (90.71 KB, text/plain)
2004-04-09 20:21 UTC, Kevin Harris
Preprocessed source when -pthread is not used. (83.19 KB, text/plain)
2004-04-09 20:21 UTC, Kevin Harris

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Harris 2004-04-09 20:19:38 UTC
Using the stream checking functions (or conversions that call those functions)
fail when -pthread is applied.  They always report the stream as being good. 
Calling the fail() function on the stream always returns false, and good()
always returns true.  These functions work as expected when -pthread is not used.

I have executed all of these tests in the debugger, and the stream testing
functions are never entered to perform these tests--it acts like a boolean value
was used in place of the function call--when -pthread was applied.  

The same erroneous functionality can be obtained by adding a #define
_THREAD_SAFE to the top of the source.

Proper execution can be obtained by using a static cast to convert the ifstream
to an istream (strange, but this works):
while(static_cast<std::istream&>(file)) { ... }

All other stream operations function correctly when the stream is used through
the istream reference.

I have verified proper operation of this test case under Linux, using various
versions of g++.

Attempts to duplicate the problem using a stringstream (to simplify the test
case) fail, as the stringstream acts properly.  Other stream types and
user-defined streams derived from std::istream fail.

// file: stream_test.cpp
// To break this (gcc-3.3.3):
// g++ stream_test.cpp -o stream_test -pthread
// To allow it to work, just remove the -pthread:
// g++ stream_test.cpp -o stream_test

#include <fstream>
#include <iostream>

int main(int argc, char** argv)
  (void) argc;
  (void) argv;
  std::ifstream file("stream_test.cpp");

    char c;
    std::cout << c << std::flush;
  return 0;
$ g++ -v
Reading specs from /usr/local/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.3.3/specs
Configured with: /mnt/nfs_kevin/foo/gcc-3.3.3/configure --prefix=/usr/local
--enable-shared --enable-threads --disable-multilib --enable-languages=c,c++
--enable-symvers=no : (reconfigured) /mnt/nfs_kevin/foo/gcc-3.3.3/configure
--prefix=/usr/local --enable-shared --enable-threads --disable-multilib
--enable-languages=c,c++ --enable-symvers=no --disable-nls
Thread model: aix
gcc version 3.3.3

Note: This has had the 'collect2.c' patch from Bug 13878 applied, and the C++
standard library /usr/local/lib/libstdc++.a has had all of the static members
removed (which were included due to another bug, number now forgotten) so that
only the dynamic library is present:

$ dump -a /usr/local/lib/libstdc++.a
                        ***Archive Header***
Member Name            Date                Uid        Gid     Mode      Size
libstdc++.so.5 Apr 07 20:53:54 2004          0          0    000755  0x005ad304
Comment 1 Kevin Harris 2004-04-09 20:21:09 UTC
Created attachment 6068 [details]
Preprocessed source when -pthread is used
Comment 2 Kevin Harris 2004-04-09 20:21:43 UTC
Created attachment 6069 [details]
Preprocessed source when -pthread is not used.
Comment 3 Kevin Harris 2004-04-12 23:48:45 UTC
I have also found this erroneous behavior with cvs version 3.3.4 (20040412),
which was compiled with no modifications.

The sample code, when compiled with gcc-3.3.2 (ltconfig/collect2.c patched),
works correctly.

Comment 4 Andrew Pinski 2004-04-13 12:47:16 UTC
Does this work in a 3.4 prerelease?
Comment 5 Kevin Harris 2004-04-13 16:33:33 UTC
The 3.4 prerelease won't compile.  The assembler is at fault, as it gets stuck
in an infinite loop while building the C++ standard library.  I even attached a
debugger to it and watched it spin on about 6 instructions.  The gcc
platform-specific information page says there's an APAR for it which is TBD, but
 I couldn't find a patch for it on the IBM web site.
Comment 6 David Edelsohn 2004-04-27 18:27:52 UTC
The AIX as and ar patches for AIX 5.1 and AIX 5.2 now are available from the IBM
Techsupport website.
Comment 7 Kevin Harris 2004-05-13 18:34:13 UTC
I was finally able to get the latest IBM patches installed, and gcc 3.4 (3.4.1
20040511) does work properly for this test.
Comment 8 Andrew Pinski 2004-05-13 18:37:41 UTC
Closing as fixed for 3.4.1.