From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Kosnik To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/2: valarray assignment operators don't resize Date: Tue, 24 Aug 1999 11:07:00 -0000 Message-id: <19990824180704.5880.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00000.html List-Id: The following reply was made to PR libstdc++/2; it has been noted by GNATS. From: Benjamin Kosnik To: rob@geonexuscorp.com Cc: libstdc++-gnats@sourceware.cygnus.com, gdr@sourceware.cygnus.com Subject: Re: libstdc++/2: valarray assignment operators don't resize Date: Tue, 24 Aug 1999 11:00:14 -0700 (PDT) > >Number: 2 > >Category: libstdc++ > >Synopsis: valarray assignment operators don't resize > >Confidential: no > >Severity: serious > >Priority: high > >Responsible: unassigned > >State: open > >Class: sw-bug > >Submitter-Id: net > >Arrival-Date: Mon Aug 23 20:47:00 PDT 1999 > >Closed-Date: > >Last-Modified: > >Originator: Robert Campbell > >Release: 2.90.6 > >Organization: > >Environment: > RedHat Linux 5.2 with glibc libraries > >Description: > The various valarray::operator=(...) methods do not > resize the object as it should. This results in core dumps if > the target objects allocated memory is smaller than the sources. thanks! this looks like a very well-formulated bug report. I appreciate you taking the time to do this. Gaby's the person for the numerics and libstdc+-v3, and valarray is entirely under his domain. I'll pass it off to him after he gets back from Africa, and expect he'll get in touch with you shortly afterwards. thanks, benjamin >>From bmosher@csc.com Wed Aug 25 11:47:00 1999 From: bmosher@csc.com To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/3: Segmentation Faults in substr() and string() Date: Wed, 25 Aug 1999 11:47:00 -0000 Message-id: <19990825183951.9939.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00001.html Content-length: 2730 >Number: 3 >Category: libstdc++ >Synopsis: Segmentation Faults in substr() and string() >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Wed Aug 25 11:47:00 PDT 1999 >Closed-Date: >Last-Modified: >Originator: Bob Mosher, Computer Sciences Corporation (210)733-4825 >Release: 2.8.1, 2.8.1.1 >Organization: >Environment: SPARC Ultra 60, Solaris 2.6, gcc 2.8.1 >Description: Example One ( segfault in substr() ): This segfault happens after correctly handling five other substr() calls in three separate source code modules. I've tried: - string s = current_line(21,4); - string s = current_line(21); - string s(current_line,21,4); - string s(current_line,21); - removing and reinstalling the compiler and associated libraries; - replacing the RAM; Nothing helps. Source code snippet: ulong rta:: ParseConnectionNumber(string current_line ) { string s = current_line; unsigned long connection_number = 0; string cnumber = s.substr(21); // segfault here return connection_number; } Error message reported by gdb: Program received signal SIGSEGV, Segmentation fault. 0x1bbe8 in basic_string, __default_alloc_template >::replace (this=0xefffefc8, pos=0, n1=0, s=0xa6d25 " 157", n2=4) at stl/stl_alloc.h:407 stl/stl_alloc.h:407: No such file or directory. stl_alloc.h is present and I had "-I/usr/local/include/g++" in the makefile. Example Two ( segfault in string() ): If I comment out the offending line in Example One, Example Two appears in a different code module. The while() loop correctly processes eleven lines of text before segfaulting on the twelfth, which is a blank line. Of the eleven lines correctly processed, two were blank. You'll note the error messages are nearly identical. Source code snippet: Parse44(): int i = 24; while(!found) { fin.getline( buffer, LINELENGTH, '\n' ); cout << "Parse44() buffer[" << i << "] = " << buffer << endl; str = string(buffer); // segfault here cout << "Parse44() str = " << str << endl; } Error message reported by gdb: Program received signal SIGSEGV, Segmentation fault. 0x1bb58 in basic_string, __default_alloc_template >::replace (this=0xeffff050, pos=0, n1=0, s=0xeffff170 "", n2=0) at stl/stl_alloc.h:407 stl/stl_alloc.h:407: No such file or directory. >How-To-Repeat: I wish I could keep it from repeating. >Fix: Not a clue. >Release-Note: >Audit-Trail: >Unformatted: >>From bkoz@cygnus.com Wed Aug 25 13:07:00 1999 From: Benjamin Kosnik To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/3: Segmentation Faults in substr() and string() Date: Wed, 25 Aug 1999 13:07:00 -0000 Message-id: <19990825200704.25252.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00002.html Content-length: 2148 The following reply was made to PR libstdc++/3; it has been noted by GNATS. From: Benjamin Kosnik To: bmosher@csc.com Cc: libstdc++-gnats@sourceware.cygnus.com, GNATS Management , nobody@sourceware.cygnus.com, libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/3: Segmentation Faults in substr() and string() Date: Wed, 25 Aug 1999 12:59:55 -0700 (PDT) Bob. This database is for the libstdc++-v3 project, not the libstdc++-v2 that comes with gcc-2.8.1. I'd test this for you with v-3, but cannot as your examples are not self-contained. I need something I can just compile and debug, not bits of your code with dangling class defintions and method calls-- > > Source code snippet: > ulong > rta:: ParseConnectionNumber(string current_line ) > { > string s = current_line; > unsigned long connection_number = 0; > > string cnumber = s.substr(21); // segfault here > > return connection_number; > } > what I'd need, is a minimal example that reproduces this. I cannot compile this as I don't know the defs for the class rta, or how this method is called. Kay? > If I comment out the offending line in Example One, Example Two appears > in a different code module. The while() loop correctly processes > eleven lines of text before segfaulting on the twelfth, which is a > blank line. Of the eleven lines correctly processed, two were blank. > You'll note the error messages are nearly identical. > > Source code snippet: > Parse44(): > int i = 24; > while(!found) > { > fin.getline( buffer, LINELENGTH, '\n' ); > cout << "Parse44() buffer[" << i << "] = " << buffer << endl; > str = string(buffer); // segfault here > cout << "Parse44() str = " << str << endl; > } > Again, I need more info. That being said, I can say that making the string class more robust was one of the goals of v-3, and what is currently shipping actually passes commercial validation suites for chapter 21. -benjamin >>From jihem@math.ucdavis.edu Wed Aug 25 13:27:00 1999 From: jihem@math.ucdavis.edu To: libstdc++-gnats@sourceware.cygnus.com Cc: gdr@sourceware.cygnus.com Subject: libstdc++/4: Floats in std_cmath.h Date: Wed, 25 Aug 1999 13:27:00 -0000 Message-id: <19990825202459.26886.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00003.html Content-length: 951 >Number: 4 >Category: libstdc++ >Synopsis: Floats in std_cmath.h >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Wed Aug 25 13:27:09 PDT 1999 >Closed-Date: >Last-Modified: >Originator: Jean-Marie Aubry >Release: gcc version 2.95.1 and libstdc++-2.90.6 >Organization: >Environment: i686-pc-linux-gnu >Description: Hello everybody, With gcc version 2.95.1 and libstdc++-2.90.6 on an i686-pc-linux-gnu, the following code: #include int main() { sin(static_cast(0)); return 0; } compiles but the executable generates a Segmentation Fault. This happens with any math function in place of the sin. With double instead of float it runs fine. What's going on there ? -- JiheM >How-To-Repeat: see above >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>From hob@scali.com Thu Aug 26 03:37:00 1999 From: hob@scali.com To: libstdc++-gnats@sourceware.cygnus.com Cc: rws@scali.no Subject: libstdc++/5: libstdc++ is not transparent to -malign-double egcs switch Date: Thu, 26 Aug 1999 03:37:00 -0000 Message-id: <19990826102803.20536.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00004.html Content-length: 965 >Number: 5 >Category: libstdc++ >Synopsis: libstdc++ is not transparent to -malign-double egcs switch >Confidential: no >Severity: serious >Priority: high >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Thu Aug 26 03:37:04 PDT 1999 >Closed-Date: >Last-Modified: >Originator: Håkon O. Bugge >Release: 2.9.0 >Organization: >Environment: RH 6.0, egcs 1.1.2, x86 >Description: Applications using libio.h (f. eks.) cannot be compiled with "-malign-double" egcs switch. If it does, the size of struct _IO_FILE changes, and the application crashes. >How-To-Repeat: Example: ---------- #include #include int main() { printf("sizeof(struct _IO_FILE) = %3d\n", sizeof(struct _IO_FILE)); return 0; } ----------- The program above yields different result compiled with -m{no-}align-double >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>From clasen@mathematik.uni-freiburg.de Mon Aug 30 12:27:00 1999 From: clasen@mathematik.uni-freiburg.de To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/6: SIGILL in __builtin_new Date: Mon, 30 Aug 1999 12:27:00 -0000 Message-id: <19990830191725.7286.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00005.html Content-length: 2538 >Number: 6 >Category: libstdc++ >Synopsis: SIGILL in __builtin_new >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Mon Aug 30 12:27:02 PDT 1999 >Closed-Date: >Last-Modified: >Originator: clasen@mathematik.uni-freiburg.de >Release: 2.95 >Organization: >Environment: RedHat 6.0/i386 with gcc-2.95-4.i386.rpm and libstdc++-2.95-4.i386.rpm from contrib.redhat.com installed. >Description: I get a SIGILL from any C++ program that uses new[] on a template class. Maybe the libstdc++-rpm is just broken, I would have tried to verify this by reinstalling from source, but there is no src.rpm on contrib.redhat.com... >How-To-Repeat: Here is a little example program that exhibits the problem: //START #include template class test { public: test() : x_(0) { printf("test::test()\n"); } test(T x) : x_(x) { printf("test::test(%d)\n", int(x)); } T value() { return x_; } private: T x_; }; //END Here is what I get from compiling and running it: bash$ make test g++ test.cc -o test bash$ ./test Illegal instruction (core dumped) bash$ gdb ./test core GNU gdb 4.17.0.11 with Linux support Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `./test'. Program terminated with signal 4, Ungültiger Maschinenbefehl. Reading symbols from /usr/lib/libstdc++-libc6.1-2.so.3...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. #0 0x4004f240 in __builtin_new (sz=20) (gdb) bt #0 0x4004f240 in __builtin_new (sz=20) #1 0x4004f443 in __builtin_vec_new (sz=20) #2 0x804866a in main () #3 0x40096cb3 in __libc_start_main (main=0x8048650
, argc=1, argv=0xbffff884, init=0x80484ac <_init>, fini=0x8048788 <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff87c) at ../sysdeps/generic/libc-start.c:78 Current language: auto; currently c++ (gdb) int main (int argc, char **argv) { test *u = 0; u = new test[5]; return 0; } >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>From bkoz@cygnus.com Tue Aug 31 17:50:00 1999 From: bkoz@cygnus.com To: bkoz@cygnus.com, bmosher@csc.com, libstdc++-prs@sourceware.cygnus.com, nobody@sourceware.cygnus.com Subject: Re: libstdc++/3 Date: Tue, 31 Aug 1999 17:50:00 -0000 Message-id: <19990901005047.15910.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00006.html Content-length: 483 Synopsis: Segmentation Faults in substr() and string() Responsible-Changed-From-To: unassigned->bkoz Responsible-Changed-By: bkoz Responsible-Changed-When: Tue Aug 31 17:50:47 1999 Responsible-Changed-Why: taking responsibility for this. . . State-Changed-From-To: open->feedback State-Changed-By: bkoz State-Changed-When: Tue Aug 31 17:50:47 1999 State-Changed-Why: awaiting a response. . http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=3 >>From bkoz@cygnus.com Tue Aug 31 18:00:00 1999 From: bkoz@cygnus.com To: bkoz@cygnus.com, clasen@mathematik.uni-freiburg.de, libstdc++-prs@sourceware.cygnus.com, nobody@sourceware.cygnus.com Subject: Re: libstdc++/6 Date: Tue, 31 Aug 1999 18:00:00 -0000 Message-id: <19990901010026.17453.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00007.html Content-length: 742 Synopsis: SIGILL in __builtin_new Responsible-Changed-From-To: unassigned->bkoz Responsible-Changed-By: bkoz Responsible-Changed-When: Tue Aug 31 18:00:26 1999 Responsible-Changed-Why: taking it. . . State-Changed-From-To: open->closed State-Changed-By: bkoz State-Changed-When: Tue Aug 31 18:00:26 1999 State-Changed-Why: 1) not with v-3, with the 2.95 release. 2) can't be reproduced with any release. I've tried: a) RH6 g++/libstdc++ (based on egcs1.1.2) b) egcs CVS c) egcs-2.95 hosted on RH6 looks like an installation error. Get the sources from egcs.cygnus.com for the 2.95 release and try building it yourself. . . . http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=6 >>From bkoz@cygnus.com Tue Aug 31 18:02:00 1999 From: bkoz@cygnus.com To: bkoz@cygnus.com, jihem@math.ucdavis.edu, libstdc++-prs@sourceware.cygnus.com, nobody@sourceware.cygnus.com Subject: Re: libstdc++/4 Date: Tue, 31 Aug 1999 18:02:00 -0000 Message-id: <19990901010229.18597.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00008.html Content-length: 957 Synopsis: Floats in std_cmath.h Responsible-Changed-From-To: unassigned->bkoz Responsible-Changed-By: bkoz Responsible-Changed-When: Tue Aug 31 18:02:29 1999 Responsible-Changed-Why: looking at this whilest gaby is in africa State-Changed-From-To: open->feedback State-Changed-By: bkoz State-Changed-When: Tue Aug 31 18:02:29 1999 State-Changed-Why: This fixes it. It's messy, but the autoconf wrangling continues. . . 1999-08-25 Benjamin Kosnik * acconfig.h: Add absf, cosf. * configure.in (use_builtin_sinf): Same. * configure: Regenerate. * bits/std_cmath.h: Add mess of defines. * testsuite/26_numerics/modf_float.cc: Change to * testsuite/26_numerics/c_math.cc: This. * src/locale.cc: Change. * bits/locale_facets.h: Fix. * testsuite/22_locale/ctype.cc: Add temporary tests. http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=4 >>From bkoz@cygnus.com Tue Aug 31 18:10:00 1999 From: bkoz@cygnus.com To: bkoz@cygnus.com, hob@scali.com, libstdc++-prs@sourceware.cygnus.com, nobody@sourceware.cygnus.com Subject: Re: libstdc++/5 Date: Tue, 31 Aug 1999 18:10:00 -0000 Message-id: <19990901011030.21592.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00009.html Content-length: 1146 Synopsis: libstdc++ is not transparent to -malign-double egcs switch Responsible-Changed-From-To: unassigned->bkoz Responsible-Changed-By: bkoz Responsible-Changed-When: Tue Aug 31 18:10:29 1999 Responsible-Changed-Why: taking it. . . State-Changed-From-To: open->feedback State-Changed-By: bkoz State-Changed-When: Tue Aug 31 18:10:29 1999 State-Changed-Why: Hmm. I'm able to compile this: #include #include #include int main() { printf("sizeof(struct _IO_FILE) = %3d\n", sizeof(struct _IO_FILE)); cout<<"this crashes then"<>From tphillips@iee.org Fri Sep 03 04:07:00 1999 From: tphillips@iee.org To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/7: Build fails on Intel/Solaris 2.7 Date: Fri, 03 Sep 1999 04:07:00 -0000 Message-id: <19990903105847.12253.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00010.html Content-length: 2285 >Number: 7 >Category: libstdc++ >Synopsis: Build fails on Intel/Solaris 2.7 >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Fri Sep 03 04:07:01 PDT 1999 >Closed-Date: >Last-Modified: >Originator: tphillips@iee.org >Release: 2.90.6 >Organization: >Environment: Intel Solaris dual processor with Solaris 2.7 GNU gcc version 2.95 gmake 3.77 >Description: The build of the libstdc++ library fails and recommends reporting a bug. The following is the tail of the make output: In file included from /usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/limits.h:117, from /usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/syslimits.h:7, from /usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/limits.h:11, from ../bits/std_climits.h:38, from ../bits/localefwd.h:38, from ../bits/std_locale.h:37, from locale-inst.cc:40: /usr/include/limits.h:204: warning: `DBL_MAX' redefined /usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/float.h:63: warning: this is the location of the previous definition /usr/include/limits.h:206: warning: `DBL_MIN' redefined /usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/float.h:54: warning: this is the location of the previous definition /usr/include/limits.h:209: warning: `FLT_MAX' redefined /usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/float.h:35: warning: this is the location of the previous definition /usr/include/limits.h:210: warning: `FLT_MIN' redefined /usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/float.h:26: warning: this is the location of the previous definition ../bits/string.tcc:54: Internal compiler error in `dwarfout_finish', at dwarfout.c:6098 Please submit a full bug report. See for instructions. make[1]: *** [locale-inst.lo] Error 1 make[1]: Leaving directory `/usr5/gnu/libstdc++-2.90.6/src' make: *** [all-recursive] Error 1 *** Error code 2 make: Fatal error: Command failed for target `all-recursive-am' >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>From dek@cgl.ucsf.edu Tue Sep 07 09:57:00 1999 From: dek@cgl.ucsf.edu To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/8: writing large strings to an ofstream causes stream to go bad Date: Tue, 07 Sep 1999 09:57:00 -0000 Message-id: <19990907165205.15459.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00011.html Content-length: 1275 >Number: 8 >Category: libstdc++ >Synopsis: writing large strings to an ofstream causes stream to go bad >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Tue Sep 07 09:57:01 PDT 1999 >Closed-Date: >Last-Modified: >Originator: dek@cgl.ucsf.edu >Release: libstdc++ 2.90 current CVS (as of Sept 6) >Organization: >Environment: Mandrake Linux 6.0 w/ gcc-2.95 >Description: Writing large (>5000 bytes) strings to an ofstream causes the ofstream to go "bad". >How-To-Repeat: #include #include const int i_max=250; void test(int size) { int i; string filename; std::ofstream f("out.log"); std::cout << "Testing with size " << size << std::endl; std::cout << "State of f:" << f.good() << std::endl; string x(size, 'c'); f << x << endl; std::cout << "State of f:" << f.good() << std::endl; if (!f.good()) exit(1); f << x << endl; std::cout << "State of f:" << f.good() << std::endl; if (!f.good()) exit(1); f.close(); return; } int main() { test(1000); test(10000); } >Fix: ? Perhaps an internal buffer is only 4k. >Release-Note: >Audit-Trail: >Unformatted: >>From mjollnir@citysearch.com Thu Sep 09 21:07:00 1999 From: mjollnir@citysearch.com To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/9: libstdc++.2.9.0.6 does NOT build on Solaris2.6 with gcc2.95 or native CC Date: Thu, 09 Sep 1999 21:07:00 -0000 Message-id: <19990910040205.21252.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00012.html Content-length: 1638 >Number: 9 >Category: libstdc++ >Synopsis: libstdc++.2.9.0.6 does NOT build on Solaris2.6 with gcc2.95 or native CC >Confidential: no >Severity: serious >Priority: high >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Thu Sep 09 21:07:00 PDT 1999 >Closed-Date: >Last-Modified: >Originator: mjollnir@citysearch.com >Release: libstdc++-2.9.0.6 >Organization: >Environment: Solaris-2.6 E-250 Compilers tried: gcc-2.8.1, gcc-2.95.1, SUNWspro/bin/cc >Description: bash-2.02# make make all-recursive Making all in math Making all in string Making all in libio Making all in src make: Fatal error in reader: Makefile, line 484: Extra `:', `::', or `:=' on dependency line Current working directory /opt/libstdc++-2.90.6/src *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /opt/libstdc++-2.90.6 *** Error code 1 make: Fatal error: Command failed for target `all-recursive-am' bash-2.02# cd src bash-2.02# vi Makefile line 484 is next one but last in this excerpt: myinstallheaders: $(headers:%=$(myincludepfx)%) @for i in $(std_headers); do \ echo "$(INSTALL_DATA) $(top_srcdir)/std/$$i $(myincludepfx)"; \ $(INSTALL_DATA) $(top_srcdir)/std/$$i $(myincludepfx); \ done $(INSTALL_DATA) $(top_builddir)/bits/std_limits.h $(myincludepfx)/bits $(INSTALL_DATA) $(top_builddir)/bits/c++config.h $(myincludepfx)/bits >How-To-Repeat: Run configure Run make >Fix: ? Looks OK to my eyes >Release-Note: >Audit-Trail: >Unformatted: >>From dosreisATcmla.ens-cachan.fr Tue Sep 14 06:17:00 1999 From: Gabriel Dos Reis To: nobody AT sourceware.cygnus.com Cc: libstdc++-prs AT sourceware.cygnus.com Subject: Re: libstdc++/2: valarray assignment operators don't resize Date: Tue, 14 Sep 1999 06:17:00 -0000 Message-id: <19990914131700.3214.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00013.html Content-length: 1699 The following reply was made to PR libstdc++/2; it has been noted by GNATS. From: Gabriel Dos Reis To: Benjamin Kosnik Cc: rob@geonexuscorp.com, libstdc++-gnats@sourceware.cygnus.com, gdr@sourceware.cygnus.com Subject: Re: libstdc++/2: valarray assignment operators don't resize Date: 14 Sep 1999 15:07:53 +0200 Benjamin Kosnik writes: | > >Number: 2 | > >Category: libstdc++ | > >Synopsis: valarray assignment operators don't resize | > >Confidential: no | > >Severity: serious | > >Priority: high | > >Responsible: unassigned | > >State: open | > >Class: sw-bug | > >Submitter-Id: net | > >Arrival-Date: Mon Aug 23 20:47:00 PDT 1999 | > >Closed-Date: | > >Last-Modified: | > >Originator: Robert Campbell | > >Release: 2.90.6 | > >Organization: | > >Environment: | > RedHat Linux 5.2 with glibc libraries | > >Description: | > The various valarray::operator=(...) methods do not | > resize the object as it should. They don't have to. 26.3.2.2 valarray assignment 1 ... The resulting behaviour is undefined if the length of the argument array is not equal to the length of the *this array. Furthermore: 26.3.2.6/3 If the array and the argument array do not have the same length, the behavior is undefined. I deliberately decided not to check array's length because valarrays are basic building blocks and valarray operations are intended to be primitive ones. It is the user's responsability to check bound, in the same way he has to be cautious when deferencing pointer. -- Gaby >>From Roman.Kagan@itep.ru Sat Sep 18 10:47:00 1999 From: Roman.Kagan@itep.ru To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/10: _Expr<>.sum() in bits/valarray_meta.h doesn't compile Date: Sat, 18 Sep 1999 10:47:00 -0000 Message-id: <19990918174329.25572.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00014.html Content-length: 1972 >Number: 10 >Category: libstdc++ >Synopsis: _Expr<>.sum() in bits/valarray_meta.h doesn't compile >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Sat Sep 18 10:47:01 PDT 1999 >Closed-Date: >Last-Modified: >Originator: Roman Kagan >Release: 2.90.6 and 2.10.0 (bundled with gcc-2.95.1) >Organization: >Environment: i686 linux-2.2.10 glibc-2.1.1 gcc-2.95.1 >Description: Template class _Expr in bits/valarray_meta.h has method sum(), which starts with line _Tp __s(_Tp()); It is (incorrectly?) interpreted by g++ as a function declaration rather than an object definition with initialization (BTW so do other compilers - KCC, IBM xlC, HP aCC). Such behavior is also mentioned as a known bug of gcc (see http://gcc.gnu.org/bugs.html , section "Parse errors for "simple" code"). >How-To-Repeat: #include main() { std::valarray a(3); (a * a).sum(); } >Fix: --- libstdc++-2.90.6/bits/valarray_meta.h~ Thu Jun 10 23:05:29 1999 +++ libstdc++-2.90.6/bits/valarray_meta.h Sat Sep 18 20:37:27 1999 @@ -716,14 +716,14 @@ inline size_t _Expr<_Clos,_Tp>::size () const { return _M_closure.size (); } - // XXX: replace this with a more robust summation algorithm. template inline _Tp _Expr<_Clos,_Tp>::sum () const { - _Tp __s(_Tp()); - size_t __n (_M_closure.size ()); - for (size_t __i=0; __i<__n; ++__i) __s += _M_closure[__i]; + size_t __i (_M_closure.size ()); + if(!__i) return _Tp(); + _Tp __s(_M_closure[--__i]); + while(__i) __s += _M_closure[--__i]; return __s; } It also reduces the number of temporaries and constructor calls, which might be worth doing to the rest of the valarray files. >Release-Note: >Audit-Trail: >Unformatted: >>From bkoz@cygnus.com Thu Sep 23 02:05:00 1999 From: bkoz@cygnus.com To: bkoz@cygnus.com, dek@cgl.ucsf.edu, libstdc++-prs@sourceware.cygnus.com, nobody@sourceware.cygnus.com Subject: Re: libstdc++/8 Date: Thu, 23 Sep 1999 02:05:00 -0000 Message-id: <19990923090527.19874.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00015.html Content-length: 643 Synopsis: writing large strings to an ofstream causes stream to go bad Responsible-Changed-From-To: unassigned->bkoz Responsible-Changed-By: bkoz Responsible-Changed-When: Thu Sep 23 02:05:27 1999 Responsible-Changed-Why: io/buffers, mine State-Changed-From-To: open->feedback State-Changed-By: bkoz State-Changed-When: Thu Sep 23 02:05:27 1999 State-Changed-Why: Looks to be fixed with stringstreams and fstreams as of this patch: 1999-09-23 Benjamin Kosnik * bits/streambuf.tcc: Yeah. Fix this for real. http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=8 >>From bkoz@cygnus.com Thu Sep 23 02:07:00 1999 From: bkoz@cygnus.com To: bkoz@cygnus.com, libstdc++-prs@sourceware.cygnus.com, mjollnir@citysearch.com, nobody@sourceware.cygnus.com Subject: Re: libstdc++/9 Date: Thu, 23 Sep 1999 02:07:00 -0000 Message-id: <19990923090703.19995.qmail@egcs.cygnus.com> X-SW-Source: 1999-q3/msg00016.html Content-length: 503 Synopsis: libstdc++.2.9.0.6 does NOT build on Solaris2.6 with gcc2.95 or native CC Responsible-Changed-From-To: unassigned->bkoz Responsible-Changed-By: bkoz Responsible-Changed-When: Thu Sep 23 02:07:03 1999 Responsible-Changed-Why: I'm dealing with this State-Changed-From-To: open->feedback State-Changed-By: bkoz State-Changed-When: Thu Sep 23 02:07:03 1999 State-Changed-Why: waiting for feedback or state http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=9 >>From aschmidt@lynet.de Thu Oct 14 04:27:00 1999 From: aschmidt@lynet.de To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/11: invalid type for default argument Date: Thu, 14 Oct 1999 04:27:00 -0000 Message-id: <19991014112640.16051.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00000.html Content-length: 1181 >Number: 11 >Category: libstdc++ >Synopsis: invalid type for default argument >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Thu Oct 14 04:27:00 PDT 1999 >Closed-Date: >Last-Modified: >Originator: aschmidt@lynet.de >Release: gcc 2.95.1 >Organization: >Environment: sparc-sun-solaris2.6 >Description: I want to compile a c++-program, which includes 'iostream.h'. I get the following errors: /opt/gcc-2.95.1/include/g++/iostream.h:50: invalid type `void *' for default argument to `ostream *' /opt/gcc-2.95.1/include/g++/iostream.h:123: invalid type `void *' for default argument to `ostream *' /opt/gcc-2.95.1/include/g++/iostream.h:231: invalid type `void *' for default argument to `ostream *' and the compiling ends. This means: The default argument NULL is not of type 'ostream*'. With 'gcc 2.8.1' i gets the same messages, but they were only warnings. How can i fix it? The changing of the "standard includes" is a bad idea. Thanks, Andreas >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>From bkoz@cygnus.com Thu Oct 14 09:07:00 1999 From: Benjamin Kosnik To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/11: invalid type for default argument Date: Thu, 14 Oct 1999 09:07:00 -0000 Message-id: <19991014160700.17258.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00001.html Content-length: 486 The following reply was made to PR libstdc++/11; it has been noted by GNATS. From: Benjamin Kosnik To: aschmidt@lynet.de Cc: libstdc++-gnats@sourceware.cygnus.com Subject: Re: libstdc++/11: invalid type for default argument Date: Thu, 14 Oct 1999 09:00:33 -0700 (PDT) Try including just , not Also, please include a sample program so that we can verify your problem. I have no idea what what the specifics are. Thanks, Benjamin >>From michaelv@edifecs.com Fri Nov 12 20:47:00 1999 From: michaelv@edifecs.com To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/12: libstdc++ 2.90.6 doesn't build on FreeBSD 3.1 Date: Fri, 12 Nov 1999 20:47:00 -0000 Message-id: <19991113043901.7931.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00002.html Content-length: 2051 >Number: 12 >Category: libstdc++ >Synopsis: libstdc++ 2.90.6 doesn't build on FreeBSD 3.1 >Confidential: no >Severity: critical >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Fri Nov 12 20:47:01 PST 1999 >Closed-Date: >Last-Modified: >Originator: michaelv@edifecs.com >Release: 2.90.6 >Organization: >Environment: FreeBSD 3.1, gmake v3.77, gcc v2.95.2, Pentium 266, 64MB RAM >Description: Can't build on FreeBSD. Part way through the build it comes up with undefined symbols: gmake all-recursive gmake[1]: Entering directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6' Making all in math gmake[2]: Entering directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6/math' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6/math' Making all in string gmake[2]: Entering directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6/string' /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c wmemcmp.c rm -f .libs/wmemcmp.lo gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c -fPIC -DPIC wmemcmp.c -o .libs/wmemcmp.lo wmemcmp.c: In function `wmemcmp': wmemcmp.c:36: `wint_t' undeclared (first use in this function) wmemcmp.c:36: (Each undeclared identifier is reported only once wmemcmp.c:36: for each function it appears in.) wmemcmp.c:36: parse error before `c1' wmemcmp.c:41: `c1' undeclared (first use in this function) wmemcmp.c:41: parse error before `s1' wmemcmp.c:42: `c2' undeclared (first use in this function) wmemcmp.c:42: parse error before `s2' gmake[2]: *** [wmemcmp.lo] Error 1 gmake[2]: Leaving directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6/string' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6' gmake: *** [all-recursive-am] Error 2 >How-To-Repeat: Try to build on FreeBSD >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>From bkoz@cygnus.com Fri Nov 12 21:57:00 1999 From: Benjamin Kosnik To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/12: libstdc++ 2.90.6 doesn't build on FreeBSD 3.1 Date: Fri, 12 Nov 1999 21:57:00 -0000 Message-id: <19991113055700.15849.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00003.html Content-length: 390 The following reply was made to PR libstdc++/12; it has been noted by GNATS. From: Benjamin Kosnik To: michaelv@edifecs.com Cc: libstdc++-gnats@sourceware.cygnus.com Subject: Re: libstdc++/12: libstdc++ 2.90.6 doesn't build on FreeBSD 3.1 Date: Fri, 12 Nov 1999 21:56:37 -0800 (PST) try CVS libstdc++, as changes went in after 2.90.6x that effect wchar_t. -benjamin >>From michaelv@edifecs.com Mon Nov 15 19:27:00 1999 From: michaelv@edifecs.com To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/13: make install does not work on Solaris 2.6 Date: Mon, 15 Nov 1999 19:27:00 -0000 Message-id: <19991116032222.7809.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00004.html Content-length: 3646 >Number: 13 >Category: libstdc++ >Synopsis: make install does not work on Solaris 2.6 >Confidential: no >Severity: serious >Priority: high >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Mon Nov 15 19:27:00 PST 1999 >Closed-Date: >Last-Modified: >Originator: michaelv@edifecs.com >Release: 2.90.6 and CVS sources from 11/15/99 >Organization: >Environment: Solaris 2.6, SUNWspro 5.0 installed but not used, gcc 2.95.2, gmake 3.76.1 (also tried 3.77 and 3.78 with no change), bash 2.03.0(1) >Description: The libstdc++ builds fine, but when I try to do a "make install", it fails trying to install the headers: Making install in math gmake[1]: Entering directory `/export1/libstdc++/math' gmake[2]: Entering directory `/export1/libstdc++/math' gmake[2]: Nothing to be done for `install-exec-am'. gmake[2]: Nothing to be done for `install-data-am'. gmake[2]: Leaving directory `/export1/libstdc++/math' gmake[1]: Leaving directory `/export1/libstdc++/math' Making install in string gmake[1]: Entering directory `/export1/libstdc++/string' gmake[2]: Entering directory `/export1/libstdc++/string' gmake[2]: Nothing to be done for `install-exec-am'. gmake[2]: Nothing to be done for `install-data-am'. gmake[2]: Leaving directory `/export1/libstdc++/string' gmake[1]: Leaving directory `/export1/libstdc++/string' Making install in libio gmake[1]: Entering directory `/export1/libstdc++/libio' gmake[2]: Entering directory `/export1/libstdc++/libio' gmake[2]: Nothing to be done for `install-exec-am'. gmake[2]: Nothing to be done for `install-data-am'. gmake[2]: Leaving directory `/export1/libstdc++/libio' gmake[1]: Leaving directory `/export1/libstdc++/libio' Making install in src gmake[1]: Entering directory `/export1/libstdc++/src' gmake[2]: Entering directory `/export1/libstdc++/src' /bin/sh ../mkinstalldirs /usr/local/lib /bin/sh ../libtool --mode=install .././install-sh -c libstdc++.la /usr/local/lib/libstdc++.la .././install-sh -c .libs/libstdc++.so.3.0.0 /usr/local/lib/libstdc++.so.3.0.0 (cd /usr/local/lib && rm -f libstdc++.so.3 && ln -s libstdc++.so.3.0.0 libstdc++.so.3) (cd /usr/local/lib && rm -f libstdc++.so && ln -s libstdc++.so.3.0.0 libstdc++.so) chmod +x /usr/local/lib/libstdc++.so.3.0.0 .././install-sh -c .libs/libstdc++.lai /usr/local/lib/libstdc++.la .././install-sh -c .libs/libstdc++.a /usr/local/lib/libstdc++.a ranlib /usr/local/lib/libstdc++.a chmod 644 /usr/local/lib/libstdc++.a ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - use the `-RLIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- gmake[2]: Nothing to be done for `install-data-am'. gmake[2]: Leaving directory `/export1/libstdc++/src' gmake[1]: *** No rule to make target `bits/basic_string.h', needed by `/usr/local/include/g++-v3/bits/basic_string.h'. Stop. gmake[1]: Leaving directory `/export1/libstdc++/src' gmake: *** [install-recursive] Error 1 >How-To-Repeat: Doing make install will fail every time. >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>From michaelv@edifecs.com Tue Nov 16 22:07:00 1999 From: michaelv@edifecs.com To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/14: Cannot link if std::stringstream is used Date: Tue, 16 Nov 1999 22:07:00 -0000 Message-id: <19991117060433.16298.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00005.html Content-length: 2687 >Number: 14 >Category: libstdc++ >Synopsis: Cannot link if std::stringstream is used >Confidential: no >Severity: serious >Priority: high >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Tue Nov 16 22:07:00 PST 1999 >Closed-Date: >Last-Modified: >Originator: michaelv@edifecs.com >Release: CVS souce from 11/15/99 >Organization: >Environment: Solaris 2.6, gcc 2.95.2 >Description: If I use std::stringstream in a program, I get multiple undefind symbols. The errors are: Undefined first referenced symbol in file collate type_info function /var/tmp/ccfEVnBc.o collate type_info function /var/tmp/ccfEVnBc.o locale::classic(void) /var/tmp/ccfEVnBc.o locale::_S_global /var/tmp/ccfEVnBc.o locale::operator==(locale const &) const/var/tmp/ccfEVnBc.o ios_base::ios_base(void) /var/tmp/ccfEVnBc.o ctype type_info node /var/tmp/ccfEVnBc.o ctype type_info node /var/tmp/ccfEVnBc.o locale::_Impl::~_Impl(void) /var/tmp/ccfEVnBc.o collate type_info node /var/tmp/ccfEVnBc.o collate type_info node /var/tmp/ccfEVnBc.o basic_ios >::init(basic_streambuf > *)/var/tmp/ccfEVnBc.o ctype const & use_facet >(locale const &)/var/tmp/ccfEVnBc.o ctype type_info function /var/tmp/ccfEVnBc.o ctype type_info function /var/tmp/ccfEVnBc.o locale::_S_classic /var/tmp/ccfEVnBc.o ios_base::failure::failure(basic_string, allocator > const &)/var/tmp/ccfEVnBc.o locale::operator=(locale const &) /var/tmp/ccfEVnBc.o ios_base::~ios_base(void) /var/tmp/ccfEVnBc.o ld: fatal: Symbol referencing errors. No output written to sst collect2: ld returned 1 exit status >How-To-Repeat: Try to compile/link this program, setting the #defines as appropriate: #include #include #include #ifdef DO_SSTREAM #include #endif int main() { std::string str; str = "abc"; str += "123"; printf("str: %s\n", str.c_str()); #ifdef DO_WIDE std::wstring wstr; wstr = L"xyz"; wstr += L"890"; printf("wstr: %S\n", wstr.c_str()); #endif #ifdef DO_SSTREAM std::stringstream ss; ss.str() = "abc"; ss << 123; printf("ss: %s\n", ss.str().c_str()); #ifdef DO_WIDE std::wstringstream wss; wss.str() = L"xyz"; wss << 890; printf("wss: %S\n", wss.str().c_str()); #endif #endif return 0; } >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>From crash@cygnus.com Thu Nov 18 19:07:00 1999 From: Jason Molenda To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/14 Date: Thu, 18 Nov 1999 19:07:00 -0000 Message-id: <19991119030700.9796.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00007.html Content-length: 881 The following reply was made to PR libstdc++/14; it has been noted by GNATS. From: Jason Molenda To: libstdc++-gnats@sourceware.cygnus.com Cc: Subject: Re: libstdc++/14 Date: Thu, 18 Nov 1999 19:05:50 -0800 ----- Forwarded message from Michael VanLoon ----- Date: Thu, 18 Nov 1999 14:12:27 -0800 From: Michael VanLoon To: "'libstdc++-gnats@sourceware.cygnus.com'" , "'nobody@sourceware.cygnus.com'" Subject: pending/15: Re: libstdc++/libstdc++/14 It appears I can't even update my own bug report. This bug report is bogus. I discovered that I was using the new headers, but still linking against the old library. Once I linked against the new library, this went away. FYI. ----- End forwarded message ----- >>From jsm@cygnus.com Thu Nov 18 19:07:00 1999 From: jsm@cygnus.com To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/15 Date: Thu, 18 Nov 1999 19:07:00 -0000 Message-id: <19991119030700.9801.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00006.html Content-length: 565 The following reply was made to PR libstdc++/15; it has been noted by GNATS. From: jsm@cygnus.com To: MichaelV@EDIFECS.COM, libstdc++-gnats@sourceware.cygnus.com, nobody@sourceware.cygnus.com Cc: Subject: Re: libstdc++/15 Date: 19 Nov 1999 03:06:28 -0000 Synopsis: Re: libstdc++/libstdc++/14 State-Changed-From-To: open->closed State-Changed-By: jsm State-Changed-When: Thu Nov 18 19:06:28 1999 State-Changed-Why: Errant PR; a follow-up e-mail got misdirected. http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=15&database=libstdc++ >>From Chad_Gibbons@bmc.com Mon Nov 22 10:57:00 1999 From: Chad_Gibbons@bmc.com To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/16: ios initialization bug Date: Mon, 22 Nov 1999 10:57:00 -0000 Message-id: <19991122185103.8044.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00008.html Content-length: 2008 >Number: 16 >Category: libstdc++ >Synopsis: ios initialization bug >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Mon Nov 22 10:57:00 PST 1999 >Closed-Date: >Last-Modified: >Originator: Chad_Gibbons@bmc.com >Release: 2.90.6 >Organization: >Environment: sparc Solaris 7, gcc 2.95.0 / 2.95.2, gld 2.9 >Description: While using v2.90.6 of libstdc++, I have run into a situation where the normal startup of the I/O stream library is run out of order. I believe this might be the result of an incorrect assumption in the library. If is included in any module, a static member is added from std_iostream.h: // For construction of filebuffers for cout, cin, cerr, clog et. al. static ios_base::Init __ioinit; The constructor for this object creates the file buffers for the standard I/O stream objects and sets their references via rdbuf. If, however, the constructors for those standard I/O stream objects occurs after the first call to ios_base::Init::Init(), then the pointers to these buffers are overridden and all stream operations via those objects are disabled. In practice, I have only seen this in extremely large projects (on the order of 50,000 symbols). For whatever Reason, the compiler/linker selects several modules that are initialized before the libstdc++ modules. These modules have no static data, no references to static objects, and are themselves not referenced statically -- they just happen to include . In any event, it seems the library is relying on the compiler to construct cout/cin/etc. before ios_base::Init is constructed, and that is something the language doesn't guarantee (I believe). >How-To-Repeat: I have not been able to cause the ctor list to be created in a way that exhibits this behavior unless a large project is built. >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>From bkoz@cygnus.com Mon Nov 22 11:07:00 1999 From: Benjamin Kosnik To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/16: ios initialization bug Date: Mon, 22 Nov 1999 11:07:00 -0000 Message-id: <19991122190700.10709.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00009.html Content-length: 1801 The following reply was made to PR libstdc++/16; it has been noted by GNATS. From: Benjamin Kosnik To: Chad_Gibbons@bmc.com Cc: libstdc++-gnats@sourceware.cygnus.com Subject: Re: libstdc++/16: ios initialization bug Date: Mon, 22 Nov 1999 11:06:28 -0800 (PST) Chad. Thanks for your bug report. Unfortunately, the snapshot you are using is a bit dated now, and some of the changes that have happened in the three months since we last released affected the ios_base::init member. I strongly urge you to check out the CVS sources and give it a whirl, as it also includes such things as floating point output, and lots of stringstream fixes. > The constructor for this object creates the file buffers for the standard I/O stream objects and sets their references via rdbuf. If, however, the constructors for those standard I/O stream objects occurs after the first > call to ios_base::Init::Init(), then the pointers to these buffers are overridden and all stream operations via those objects are disabled. > > In practice, I have only seen this in extremely large projects (on the order of 50,000 symbols). For whatever Reason, the compiler/linker selects several modules that are initialized before the libstdc++ modules. These modules > have no static data, no references to static objects, and are themselves not referenced statically -- they just happen to include . > > In any event, it seems the library is relying on the compiler to construct cout/cin/etc. before ios_base::Init is constructed, and that is something the language doesn't guarantee (I believe). 27.3 iostream objects goes over this requirement. I belive CVS sources now get this behavior correct, but know that the release you are using has problems. -benjamin >>From bkoz@cygnus.com Thu Dec 02 11:07:00 1999 From: Benjamin Kosnik To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: RE: libstdc++/16: ios initialization bug Date: Thu, 02 Dec 1999 11:07:00 -0000 Message-id: <19991202190659.11101.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00010.html Content-length: 5054 The following reply was made to PR libstdc++/16; it has been noted by GNATS. From: Benjamin Kosnik To: "Gibbons, Chad" Cc: libstdc++-gnats@sourceware.cygnus.com Subject: RE: libstdc++/16: ios initialization bug Date: Thu, 2 Dec 1999 10:59:06 -0800 (PST) hmmm. If this static init object is in the iostream header, then the initialization of the iostream std objects will take place before people can use things like cout/cin/cerr (as they'd need the declarations in the iostream header). If this is put into a source file, no such guarantees are in place. I don't believe you sent me a small, reproducable test case for this (but maybe I'm wrong) -- can you either correct me (I admit to being particularly flaky about this bug report, sorry) or construct one and send it to me? -benjamin On Thu, 2 Dec 1999, Gibbons, Chad wrote: > Benjamin, > > Here's the patch I'm using. It seems to work fine on our code, but I wasn't > able to run the testsuite at all (even before the patch!) to try it out... > > Index: bits/std_iostream.h > =================================================================== > RCS file: /cvs/libstdc++/libstdc++/bits/std_iostream.h,v > retrieving revision 1.11 > diff -c -3 -p -d -r1.11 std_iostream.h > *** std_iostream.h 1999/06/25 03:55:41 1.11 > --- std_iostream.h 1999/12/02 18:11:01 > *************** namespace std { > *** 50,58 **** > extern wostream wcerr; > extern wostream wclog; > #endif > - > - // For construction of filebuffers for cout, cin, cerr, clog et. al. > - static ios_base::Init __ioinit; > } // namespace std > > #endif /* _CPP_IOSTREAM */ > --- 50,55 ---- > Index: src/stdstreams.cc > =================================================================== > RCS file: /cvs/libstdc++/libstdc++/src/stdstreams.cc,v > retrieving revision 1.11 > diff -c -3 -p -d -r1.11 stdstreams.cc > *** stdstreams.cc 1999/06/25 03:56:04 1.11 > --- stdstreams.cc 1999/12/02 18:11:02 > *************** namespace std { > *** 45,48 **** > --- 45,51 ---- > wostream wclog(&__wfileinit); > #endif > > + // For construction of filebuffers for cout, cin, cerr, clog et. al. > + static ios_base::Init __ioinit; > + > } // std > > > > -----Original Message----- > From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ] > Sent: Wednesday, December 01, 1999 11:53 PM > To: Gibbons, Chad > Subject: RE: libstdc++/16: ios initialization bug > > > > aggh. Sorry. I just got back. Can you resend your patch please? I got a > bit behind. > > -benjamin > > On Wed, 1 Dec 1999, Gibbons, Chad wrote: > > > Hiya Benjamin, > > > > I sent you a message back last week or so with a pseudo-patch for this > > problem. Would it be best for me to submit a patch in the way described at > > http://sourceware.cygnus.com/libstdc++/17_intro/contribute.html ? > > > > By the way, the latest CVS sources still exhibit the behavior. > > > > Thanks again, > > Chad Gibbons > > > > -----Original Message----- > > From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ] > > Sent: Monday, November 22, 1999 1:06 PM > > To: Chad_Gibbons@bmc.com > > Cc: libstdc++-gnats@sourceware.cygnus.com > > Subject: Re: libstdc++/16: ios initialization bug > > > > > > > > Chad. > > > > Thanks for your bug report. Unfortunately, the snapshot you are using is > > a bit dated now, and some of the changes that have happened in the three > > months since we last released affected the ios_base::init member. I > > strongly urge you to check out the CVS sources and give it a whirl, as it > > also includes such things as floating point output, and lots of > > stringstream fixes. > > > > > > > The constructor for this object creates the file buffers for the > standard > > I/O stream objects and sets their references via rdbuf. If, however, the > > constructors for those standard I/O stream objects occurs after the first > > > call to ios_base::Init::Init(), then the pointers to these buffers are > > overridden and all stream operations via those objects are disabled. > > > > > > In practice, I have only seen this in extremely large projects (on the > > order of 50,000 symbols). For whatever Reason, the compiler/linker selects > > several modules that are initialized before the libstdc++ modules. These > > modules > > > have no static data, no references to static objects, and are themselves > > not referenced statically -- they just happen to include . > > > > > > In any event, it seems the library is relying on the compiler to > construct > > cout/cin/etc. before ios_base::Init is constructed, and that is something > > the language doesn't guarantee (I believe). > > > > 27.3 iostream objects goes over this requirement. I belive CVS sources > > now get this behavior correct, but know that the release you are using > > has problems. > > > > -benjamin > > > >>From Chad_Gibbons@bmc.com Thu Dec 02 12:17:00 1999 From: "Gibbons, Chad" To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: RE: libstdc++/16: ios initialization bug Date: Thu, 02 Dec 1999 12:17:00 -0000 Message-id: <19991202201700.23722.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00011.html Content-length: 6566 The following reply was made to PR libstdc++/16; it has been noted by GNATS. From: "Gibbons, Chad" To: "'Benjamin Kosnik'" , "Gibbons, Chad" Cc: libstdc++-gnats@sourceware.cygnus.com Subject: RE: libstdc++/16: ios initialization bug Date: Thu, 2 Dec 1999 14:15:00 -0600 Unfortunately, I don't have a small test program that can break the ios initialization code. We only see the behavior in an application that has an extremely large number of symbols (which causes g++/gld to place the ctors for some objects before the creation of the iostream objects). Our original problem was with code that was including and even though they didn't use it early on, it caused global constructors to be called for that module. If this line: static ios_base::Init __ioinit; is left in bits/std_iostream.h, then it is possible (on compiler/linker whims) for it to be called before the cout/cerr/etc. constructors are called. Once the constructors for those global objects are called, the file buffers that were created by ios_base::Init are replaced with null pointers. By moving the line above to src/stdstreams.cc, I was forcing the initialization of the file buffers to occur after the iostream objects are actually created. Since the initialization of the buffers is tied to the iostream's creation, you're still safe if a user tries to use ios early on (they can't use them any earlier than they've been constructed...). Thanks, Chad Gibbons -----Original Message----- From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ] Sent: Thursday, December 02, 1999 12:59 PM To: Gibbons, Chad Cc: libstdc++-gnats@sourceware.cygnus.com Subject: RE: libstdc++/16: ios initialization bug hmmm. If this static init object is in the iostream header, then the initialization of the iostream std objects will take place before people can use things like cout/cin/cerr (as they'd need the declarations in the iostream header). If this is put into a source file, no such guarantees are in place. I don't believe you sent me a small, reproducable test case for this (but maybe I'm wrong) -- can you either correct me (I admit to being particularly flaky about this bug report, sorry) or construct one and send it to me? -benjamin On Thu, 2 Dec 1999, Gibbons, Chad wrote: > Benjamin, > > Here's the patch I'm using. It seems to work fine on our code, but I wasn't > able to run the testsuite at all (even before the patch!) to try it out... > > Index: bits/std_iostream.h > =================================================================== > RCS file: /cvs/libstdc++/libstdc++/bits/std_iostream.h,v > retrieving revision 1.11 > diff -c -3 -p -d -r1.11 std_iostream.h > *** std_iostream.h 1999/06/25 03:55:41 1.11 > --- std_iostream.h 1999/12/02 18:11:01 > *************** namespace std { > *** 50,58 **** > extern wostream wcerr; > extern wostream wclog; > #endif > - > - // For construction of filebuffers for cout, cin, cerr, clog et. al. > - static ios_base::Init __ioinit; > } // namespace std > > #endif /* _CPP_IOSTREAM */ > --- 50,55 ---- > Index: src/stdstreams.cc > =================================================================== > RCS file: /cvs/libstdc++/libstdc++/src/stdstreams.cc,v > retrieving revision 1.11 > diff -c -3 -p -d -r1.11 stdstreams.cc > *** stdstreams.cc 1999/06/25 03:56:04 1.11 > --- stdstreams.cc 1999/12/02 18:11:02 > *************** namespace std { > *** 45,48 **** > --- 45,51 ---- > wostream wclog(&__wfileinit); > #endif > > + // For construction of filebuffers for cout, cin, cerr, clog et. al. > + static ios_base::Init __ioinit; > + > } // std > > > > -----Original Message----- > From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ] > Sent: Wednesday, December 01, 1999 11:53 PM > To: Gibbons, Chad > Subject: RE: libstdc++/16: ios initialization bug > > > > aggh. Sorry. I just got back. Can you resend your patch please? I got a > bit behind. > > -benjamin > > On Wed, 1 Dec 1999, Gibbons, Chad wrote: > > > Hiya Benjamin, > > > > I sent you a message back last week or so with a pseudo-patch for this > > problem. Would it be best for me to submit a patch in the way described at > > http://sourceware.cygnus.com/libstdc++/17_intro/contribute.html ? > > > > By the way, the latest CVS sources still exhibit the behavior. > > > > Thanks again, > > Chad Gibbons > > > > -----Original Message----- > > From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ] > > Sent: Monday, November 22, 1999 1:06 PM > > To: Chad_Gibbons@bmc.com > > Cc: libstdc++-gnats@sourceware.cygnus.com > > Subject: Re: libstdc++/16: ios initialization bug > > > > > > > > Chad. > > > > Thanks for your bug report. Unfortunately, the snapshot you are using is > > a bit dated now, and some of the changes that have happened in the three > > months since we last released affected the ios_base::init member. I > > strongly urge you to check out the CVS sources and give it a whirl, as it > > also includes such things as floating point output, and lots of > > stringstream fixes. > > > > > > > The constructor for this object creates the file buffers for the > standard > > I/O stream objects and sets their references via rdbuf. If, however, the > > constructors for those standard I/O stream objects occurs after the first > > > call to ios_base::Init::Init(), then the pointers to these buffers are > > overridden and all stream operations via those objects are disabled. > > > > > > In practice, I have only seen this in extremely large projects (on the > > order of 50,000 symbols). For whatever Reason, the compiler/linker selects > > several modules that are initialized before the libstdc++ modules. These > > modules > > > have no static data, no references to static objects, and are themselves > > not referenced statically -- they just happen to include . > > > > > > In any event, it seems the library is relying on the compiler to > construct > > cout/cin/etc. before ios_base::Init is constructed, and that is something > > the language doesn't guarantee (I believe). > > > > 27.3 iostream objects goes over this requirement. I belive CVS sources > > now get this behavior correct, but know that the release you are using > > has problems. > > > > -benjamin > > > >>From pbd@op.net Fri Dec 03 17:57:00 1999 From: pbd@op.net To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result Date: Fri, 03 Dec 1999 17:57:00 -0000 Message-id: <19991204015556.7643.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00012.html Content-length: 1601 >Number: 17 >Category: libstdc++ >Synopsis: cout is not a real ostream; dynamic_cast SEGV's as a result >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Fri Dec 03 17:57:00 PST 1999 >Closed-Date: >Last-Modified: >Originator: pbd@op.net >Release: 2.9.0 >Organization: >Environment: RedHat Linux, egcs 1.1.2 >Description: because cout is not a real ostream, but a _fake_ostream, dynamic_cast will fail when applied to a pointer or reference to cout. given that "ostream cout" is apparently part of the "standard library", not having cout actually be a real ostream is not good. i think. :) >How-To-Repeat: compile this program: c++ -o k.k.cc run it, watch it SEGV when attempting a dynamic cast on the pointer to cout. >Fix: cout should be a real ostream, not a _fake_ostream. >Release-Note: >Audit-Trail: >Unformatted: ----gnatsweb-attachment---- Content-Type: application/octet-stream; name="k.cc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="k.cc" I2luY2x1ZGUgPGlvc3RyZWFtPgoKY2xhc3MgVHJhbnNtaXR0ZXIgOiBwdWJsaWMgb3N0cmVhbQoK ewp9OwoKdm9pZCAKdHJ5X2Nhc3QgKG9zdHJlYW0gKm9zdHIpCgp7CglUcmFuc21pdHRlciAqdHA7 CgoJdHAgPSBkeW5hbWljX2Nhc3Q8VHJhbnNtaXR0ZXIgKj4gKG9zdHIpOwoJY291dCA8PCAidHAg PSAiIDw8IGhleCA8PCAoaW50KSB0cCA8PCBkZWMgPDwgZW5kbDsKfQkKCm1haW4gKCkKCnsKCVRy YW5zbWl0dGVyIHQ7Cglvc3RyZWFtIGZvbzsKCgl0cnlfY2FzdCAoJnQpOwoJdHJ5X2Nhc3QgKCZm b28pOwoJdHJ5X2Nhc3QgKCZjb3V0KTsKfQoJCg== >>From bkoz@cygnus.com Fri Dec 03 20:07:00 1999 From: Benjamin Kosnik To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result Date: Fri, 03 Dec 1999 20:07:00 -0000 Message-id: <19991204040700.18090.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00013.html Content-length: 659 The following reply was made to PR libstdc++/17; it has been noted by GNATS. From: Benjamin Kosnik To: pbd@op.net Cc: libstdc++-gnats@sourceware.cygnus.com Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result Date: Fri, 3 Dec 1999 20:01:52 -0800 (PST) > because cout is not a real ostream, but a _fake_ostream, > dynamic_cast will fail > when applied to a pointer or reference to cout. see http://sourceware.cygnus.com/libstdc++ that's what this database is for. . . . if you checkout the CVS sources, you'll see that cout is indeed a "real" ostream -benjamin >>From pbd@Op.Net Fri Dec 03 21:37:00 1999 From: Paul Barton-Davis To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result Date: Fri, 03 Dec 1999 21:37:00 -0000 Message-id: <19991204053700.24756.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00015.html Content-length: 1140 The following reply was made to PR libstdc++/17; it has been noted by GNATS. From: Paul Barton-Davis To: Benjamin Kosnik Cc: libstdc++-gnats@sourceware.cygnus.com Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result Date: Sat, 04 Dec 1999 00:35:55 -0500 Also: >that's what this database is for. . . . if you checkout the CVS sources, >you'll see that cout is indeed a "real" ostream When i use the web-browsing access to the CVS source, i find this in v1.1 of stdstream.cc: ---------------------------------------------------------- struct _fake_ostream { .... }; . . . #ifdef __GNUC__ #define OSTREAM_DEF(NAME, SBUF, TIE, EXTRA_FLAGS, ASM) \ _fake_ostream NAME ASM = { {&NAME.base}, {STD_STR(SBUF, TIE, EXTRA_FLAGS) }}; #else #define OSTREAM_DEF(NAME, SBUF, TIE, EXTRA_FLAGS) \ _fake_ostream NAME = { {0, &NAME.base}, {STD_STR(SBUF, TIE, EXTRA_FLAGS) }}; #endif . . . OSTREAM_DEF(cout, COUT_SBUF, NULL, 0, ) ---------------------------------------------------------- what i am not seeing ? --p >>From pbd@Op.Net Fri Dec 03 21:37:00 1999 From: Paul Barton-Davis To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result Date: Fri, 03 Dec 1999 21:37:00 -0000 Message-id: <19991204053700.24751.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00014.html Content-length: 893 The following reply was made to PR libstdc++/17; it has been noted by GNATS. From: Paul Barton-Davis To: Benjamin Kosnik Cc: libstdc++-gnats@sourceware.cygnus.com Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result Date: Sat, 04 Dec 1999 00:28:46 -0500 >> because cout is not a real ostream, but a _fake_ostream, >> dynamic_cast will fail >> when applied to a pointer or reference to cout. > >see http://sourceware.cygnus.com/libstdc++ > >that's what this database is for. . . . if you checkout the CVS sources, >you'll see that cout is indeed a "real" ostream then why does a dynamic_cast segfault when passed a pointer to cout, but not to any other ostream ? perhaps i am getting my streams implementation from some other library like libg++ ? --p >>From vladimir.kondratiev@intel.com Thu Dec 16 00:47:00 1999 From: vladimir.kondratiev@intel.com To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/18: 2.90.7 release announced but not uploaded to FTP server Date: Thu, 16 Dec 1999 00:47:00 -0000 Message-id: <19991216084059.14836.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00016.html Content-length: 551 >Number: 18 >Category: libstdc++ >Synopsis: 2.90.7 release announced but not uploaded to FTP server >Confidential: no >Severity: non-critical >Priority: low >Responsible: unassigned >State: open >Class: support >Submitter-Id: net >Arrival-Date: Thu Dec 16 00:47:00 PST 1999 >Closed-Date: >Last-Modified: >Originator: vladimir.kondratiev@intel.com >Release: unknown-1.0 >Organization: >Environment: >Description: >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>From bkoz@cygnus.com Thu Dec 16 10:37:00 1999 From: Benjamin Kosnik To: nobody@sourceware.cygnus.com Cc: libstdc++-prs@sourceware.cygnus.com Subject: Re: libstdc++/18: 2.90.7 release announced but not uploaded to FTPserver Date: Thu, 16 Dec 1999 10:37:00 -0000 Message-id: <19991216183700.26696.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00017.html Content-length: 417 The following reply was made to PR libstdc++/18; it has been noted by GNATS. From: Benjamin Kosnik To: vladimir.kondratiev@intel.com Cc: libstdc++-gnats@sourceware.cygnus.com Subject: Re: libstdc++/18: 2.90.7 release announced but not uploaded to FTP server Date: Thu, 16 Dec 1999 10:33:48 -0800 (PST) The realse is not out, the web page is in error. It will probably be monday. -benjamin >>From tomoaki@biol.s.u-tokyo.ac.jp Sat Dec 25 08:17:00 1999 From: tomoaki@biol.s.u-tokyo.ac.jp To: libstdc++-gnats@sourceware.cygnus.com Subject: libstdc++/19: _T name colision to ctype.h in FreeBSD Date: Sat, 25 Dec 1999 08:17:00 -0000 Message-id: <19991225161335.3927.qmail@sourceware.cygnus.com> X-SW-Source: 1999-q4/msg00018.html Content-length: 942 >Number: 19 >Category: libstdc++ >Synopsis: _T name colision to ctype.h in FreeBSD >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: change-request >Submitter-Id: net >Arrival-Date: Sat Dec 25 08:17:00 PST 1999 >Closed-Date: >Last-Modified: >Originator: tomoaki@biol.s.u-tokyo.ac.jp >Release: libstdc++-2.90.7 >Organization: >Environment: FreeBSD koke.nibb.ac.jp 3.3-RELEASE FreeBSD 3.3-RELEASE #0: Sun Nov 14 22:56:39 JST 1999 tomoaki@koke.nibb.ac.jp:/usr/src/sys/compile/PH i386 >Description: _T is defined as a macro in ctype.h in FreeBSD bits/slice_array.h and some other files use _T as a local identifier, but will be overriden by the macro defined in ctype.h. In many other locations, _Tp is used as a local identifier. >How-To-Repeat: >Fix: Substitute _T with _Tp >Release-Note: >Audit-Trail: >Unformatted: