This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] Fix wide charater literals (was Re: [RFC] Unexpected compiler twist of the wcscoll issue)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Paolo Carlini <pcarlini at unitus dot it>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Wed, 13 Mar 2002 05:54:01 -0500
- Subject: Re: [PATCH] Fix wide charater literals (was Re: [RFC] Unexpected compiler twist of the wcscoll issue)
- References: <3C8DF94C.D182C65D@unitus.it> <20020312170140.Q2204@sunsite.ms.mff.cuni.cz> <3C8E2880.3000307@unitus.it> <20020313053419.M2434@devserv.devel.redhat.com> <3C8F2C68.90105@unitus.it>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Mar 13, 2002 at 11:39:36AM +0100, Paolo Carlini wrote:
> Jakub Jelinek wrote:
>
> >On Tue, Mar 12, 2002 at 05:10:40PM +0100, Paolo Carlini wrote:
> >
> >>Just to be sure, have you tested also the libstdc++ testsuite on a
> >>linux-gnu system? There are many wstring literals in it and if
> >>everything is ok you should obtain 1 unexpected
> >>(c99_classification_macros_c.cc) and 0 expected failures.
> >>
> >
> >I get
> >
> >FAIL: 21_strings/ctor_copy_dtor.cc execution test
> >FAIL: 21_strings/insert.cc execution test
> >FAIL: 26_numerics/c99_classification_macros_c.cc (test for excess errors)
> >FAIL: 27_io/ostream_inserter_char.cc execution test
> >
> >glibc 2.2.90 without stdio mmap and new regex, binutils ~ 2.12.
> >Not a regression since before the patch though.
> >
> > Jakub
> >
> Thanks for your feedbcak.
> On i686? There are 3 fails which should not on i686?!?
i686 box, but configured as i386-redhat-linux.
But just checked and ctor_copy_dtor.cc fails even if compiled with
additional -march=i686.
Brief check under debugger shows that:
line 116: csz01 = 0x3ffffffc
line 140: crash:
#0 0x401743ac in sYSMALLOc () from /lib/i686/libc.so.6
#1 0x401754d3 in _int_malloc () from /lib/i686/libc.so.6
#2 0x401745c5 in malloc () from /lib/i686/libc.so.6
#3 0x40096af6 in operator new(unsigned) (sz=1073745904)
at ../../../../libstdc++-v3/libsupc++/new_op.cc:48
#4 0x400911e5 in std::string::_Rep::_S_create(unsigned, std::allocator<char> const&) (__capacity=1073745891, __alloc=@0xbfffea00) at /usr/src/gcc-3.1/obj3/i386-redhat-linux/libstdc++-v3/include/bits/stl_alloc.h:103
#5 0x40090652 in std::string::_S_construct(unsigned, char, std::allocator<char> const&) (__n=1073741819, __c=122 'z', __a=@0xbfffea00) at /usr/src/gcc-3.1/obj3/i386-redhat-linux/libstdc++-v3/include/bits/basic_string.tcc:169
#6 0x4008ef37 in basic_string (this=0xbfffe9f0, __n=1073741819, __c=122 'z', __a=@0x804e001) at /usr/src/gcc-3.1/obj3/i386-redhat-linux/libstdc++-v3/include/bits/basic_string.tcc:229
#7 0x0804948a in test01() () at /usr/src/gcc-3.1/libstdc++-v3/testsuite/21_strings/ctor_copy_dtor.cc:140
#8 0x08049a5f in main () at /usr/src/gcc-3.1/libstdc++-v3/testsuite/21_strings/ctor_copy_dtor.cc:200
#9 0x40110149 in __libc_start_main () from /lib/i686/libc.so.6
which means I think that I should:
a) back out new malloc in glibc
b) debug it
Jakub