Re: GCC 3.2 Prerelease

Re: GCC 3.2 Prerelease

[B. Kosnik]

Yes. Regardless of the Intel C++ ABI testsuite, I think my original
point needs to be addressed: mainly, that 3.2 and 3.3 are at different
C++ ABI's. I think this needs to be fixed.

-benjamin

Re: GCC 3.2 Prerelease

[Joe Buck]

> Yes. Regardless of the Intel C++ ABI testsuite, I think my original
> point needs to be addressed: mainly, that 3.2 and 3.3 are at different
> C++ ABI's. I think this needs to be fixed.

Agreed; I don't see how we can release 3.2 unless we can be confident that
3.3, when released, will have the same ABI ("fixing" 3.3 before its
release, to fix the problem, might be acceptable).  However, I must admit that I
am fuzzy about just what the breakage is; what are the differences?

Re: GCC 3.2 Prerelease

[B. Kosnik]

> Agreed; I don't see how we can release 3.2 unless we can be confident
> that 3.3, when released, will have the same ABI ("fixing" 3.3 before
> its release, to fix the problem, might be acceptable).  However, I
> must admit that I am fuzzy about just what the breakage is; what are
> the differences?

There are 155 g++ fails, and 15 libstdc++ fails, when the 3.3
libstdc++.so is used with the 3.2 toolchain.

Jakub gets different results. I'm hoping that a third person will step
forward and try this, and that this person's results will match either
Jakub or mine. I'm willing to be wrong, of course. I'm just uneasy.

In the meantime I'm backing through 3.3 sources to try and get a
compatible library.

-benjamin

Re: GCC 3.2 Prerelease

[H. J. Lu]

On Mon, Aug 05, 2002 at 06:07:25PM -0700, B. Kosnik wrote:
> 
> > Agreed; I don't see how we can release 3.2 unless we can be confident
> > that 3.3, when released, will have the same ABI ("fixing" 3.3 before
> > its release, to fix the problem, might be acceptable).  However, I
> > must admit that I am fuzzy about just what the breakage is; what are
> > the differences?
> 
> There are 155 g++ fails, and 15 libstdc++ fails, when the 3.3
> libstdc++.so is used with the 3.2 toolchain.
> 
> Jakub gets different results. I'm hoping that a third person will step
> forward and try this, and that this person's results will match either
> Jakub or mine. I'm willing to be wrong, of course. I'm just uneasy.
> 

I will give a try.


H.J.

Re: GCC 3.2 Prerelease

[Daniel Jacobowitz]

On Mon, Aug 05, 2002 at 06:07:25PM -0700, B. Kosnik wrote:
> 
> > Agreed; I don't see how we can release 3.2 unless we can be confident
> > that 3.3, when released, will have the same ABI ("fixing" 3.3 before
> > its release, to fix the problem, might be acceptable).  However, I
> > must admit that I am fuzzy about just what the breakage is; what are
> > the differences?
> 
> There are 155 g++ fails, and 15 libstdc++ fails, when the 3.3
> libstdc++.so is used with the 3.2 toolchain.
> 
> Jakub gets different results. I'm hoping that a third person will step
> forward and try this, and that this person's results will match either
> Jakub or mine. I'm willing to be wrong, of course. I'm just uneasy.
> 
> In the meantime I'm backing through 3.3 sources to try and get a
> compatible library.

Hate to do this, but I get to add to the confusion...

I tried a set of straight "../configure --enable-languages=c,c++"
builds.  Head testsuite results (libstdc++ and check-g++ only):

FAIL: g++.dg/warn/Wunused-2.C  (test for warnings, line 5)
XPASS: 22_locale/collate_byname.cc execution test
FAIL: 22_locale/ctor_copy_dtor.cc execution test
XPASS: 22_locale/ctype_is_char.cc execution test
XPASS: 22_locale/ctype_is_wchar_t.cc execution test
XPASS: 22_locale/messages_byname.cc execution test
XPASS: 22_locale/moneypunct_byname.cc execution test
FAIL: 26_numerics/c99_classification_macros_c.cc (test for excess errors)

Branch results were exactly the same.

I then swapped _only_ the libstdc++.so.5.0.0 file between the builds. 
This seems to me to be the right thing to do; none of the testsuite
uses the static version, and libsupc++ will always match the compiler
being used because it is only static.

The GCC HEAD compiler using the branch library failed:
FAIL: backward/strstream_members.cc execution test

Everything else was the same, and the branch compiler using the head
library (and the branch testsuite, mind...) had no new failures.


The new failures was:
#0  0x4016d94d in free () from /lib/libc.so.6
#1  0x4009f033 in operator delete(void*) (ptr=0x8000000)
    at /opt/src/gcc/branch32/libstdc++-v3/libsupc++/del_op.cc:39
#2  0x4009f08f in operator delete[](void*) (ptr=0x8000000)
    at /opt/src/gcc/branch32/libstdc++-v3/libsupc++/del_opv.cc:36
#3  0x40054329 in std::strstreambuf::_M_free(char*) (this=0x8000000, p=0x8049be0 "")
    at /opt/src/gcc/branch32/libstdc++-v3/src/strstream.cc:325

and I assume it's not a problem because I see that the test has changed
since the 3.2 branch.


I'm in the middle of repeating this experiment with
--enable-__cxa_atexit --enable-threads=posix.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: GCC 3.2 Prerelease

[Daniel Jacobowitz]

On Tue, Aug 06, 2002 at 08:53:51AM -0400, Daniel Jacobowitz wrote:
> I'm in the middle of repeating this experiment with
> --enable-__cxa_atexit --enable-threads=posix.

With those options, the only change is:
All four combinations XPASS's g++.other/init5.C

Benjamin, what are we doing differently?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: GCC 3.2 Prerelease

[Mark Mitchell]

The GCC HEAD compiler using the branch library failed:
FAIL: backward/strstream_members.cc execution test

Everything else was the same, and the branch compiler using the head
library (and the branch testsuite, mind...) had no new failures.

Re: GCC 3.2 Prerelease

[B. Kosnik]

> Is there any difference in the source for that test between the branch
> and head?  In other words, could the test have changed to indicate
> something changing in the library?

yes. this failure has nothing to do with an ABI change.

Re: GCC 3.2 Prerelease

[B. Kosnik]

> Benjamin, what are we doing differently?

I don't know. 

I've re-run the tests with ld-2.11.93.0.2 vs. 2.13.90. I've run
2002-07-25 sources versus today's sources. I've reproduced my results on
a second machine.

I don't know what's up, but at this point you, Jakub, and Loren have
similar results, so I'll bow out gracefully.

thanks,
benjamin

Re: GCC 3.2 Prerelease

[Phil Edwards]

On Mon, Aug 05, 2002 at 06:07:25PM -0700, B. Kosnik wrote:
> There are 155 g++ fails, and 15 libstdc++ fails, when the 3.3
> libstdc++.so is used with the 3.2 toolchain.
> 
> Jakub gets different results. I'm hoping that a third person will step
> forward and try this, and that this person's results will match either
> Jakub or mine. I'm willing to be wrong, of course. I'm just uneasy.

I'm finally far enough recovered from a fatal hard drive crash that I can
try and do this test today.  Don't wait on me, though; Lord only knows what
other crucial piece of software I'm missing that I'll discover the hard way.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC 3.2 Prerelease

[H. J. Lu]

On Mon, Aug 05, 2002 at 06:07:25PM -0700, B. Kosnik wrote:
> 
> > Agreed; I don't see how we can release 3.2 unless we can be confident
> > that 3.3, when released, will have the same ABI ("fixing" 3.3 before
> > its release, to fix the problem, might be acceptable).  However, I
> > must admit that I am fuzzy about just what the breakage is; what are
> > the differences?
> 
> There are 155 g++ fails, and 15 libstdc++ fails, when the 3.3
> libstdc++.so is used with the 3.2 toolchain.
> 
> Jakub gets different results. I'm hoping that a third person will step
> forward and try this, and that this person's results will match either
> Jakub or mine. I'm willing to be wrong, of course. I'm just uneasy.

Here is mine on Linux/x86 configured with

.../configure --enable-__cxa_atexit --enable-clocale=gnu --with-system-zlib --enable-shared --enable-threads=posix --enable-haifa --disable-checking

1. gcc 3.3 using libstdc++ from gcc 3.2. Additional failures:

+FAIL: backward/strstream_members.cc execution test
+FAIL: gcc.c-torture/compile/20001226-1.c,  -O1  
+FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -fomit-frame-pointer  

Additonal pass:

-FAIL: 22_locale/ctype_narrow_wchar_t.cc execution test

2. gcc 3.2 using libstdc++ from gcc 3.3. Additional failures:

+FAIL: 22_locale/ctype_narrow_wchar_t.cc execution test
+FAIL: Thread_Interrupt output from bytecode->native test
+FAIL: Thread_Wait_2 execution from bytecode->native test
+FAIL: Thread_Wait -O execution from source compiled test



H.J.

Re: GCC 3.2 Prerelease

[Mark Mitchell]

--On Tuesday, August 06, 2002 11:05:09 AM -0700 "H. J. Lu" <hjl@lucon.org> 
wrote:

On Mon, Aug 05, 2002 at 06:07:25PM -0700, B. Kosnik wrote:

Re: GCC 3.2 Prerelease

[H. J. Lu]

On Tue, Aug 06, 2002 at 11:20:01AM -0700, Mark Mitchell wrote:
> 
> 
> --On Tuesday, August 06, 2002 11:05:09 AM -0700 "H. J. Lu" <hjl@lucon.org> 
> wrote:
> 
> > On Mon, Aug 05, 2002 at 06:07:25PM -0700, B. Kosnik wrote:
> >>
> >> > Agreed; I don't see how we can release 3.2 unless we can be confident
> >> > that 3.3, when released, will have the same ABI ("fixing" 3.3 before
> >> > its release, to fix the problem, might be acceptable).  However, I
> >> > must admit that I am fuzzy about just what the breakage is; what are
> >> > the differences?
> >>
> >> There are 155 g++ fails, and 15 libstdc++ fails, when the 3.3
> >> libstdc++.so is used with the 3.2 toolchain.
> >>
> >> Jakub gets different results. I'm hoping that a third person will step
> >> forward and try this, and that this person's results will match either
> >> Jakub or mine. I'm willing to be wrong, of course. I'm just uneasy.
> >
> > Here is mine on Linux/x86 configured with
> >
> > .../configure --enable-__cxa_atexit --enable-clocale=gnu
> > --with-system-zlib --enable-shared --enable-threads=posix --enable-haifa
> > --disable-checking
> >
> > 1. gcc 3.3 using libstdc++ from gcc 3.2. Additional failures:
> >
> > +FAIL: backward/strstream_members.cc execution test
> > +FAIL: gcc.c-torture/compile/20001226-1.c,  -O1
> > +FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -fomit-frame-pointer
> 
> Here, you are claiming that changing the C++ library broke the C
> compiler.  Are you sure about that?

I got

WARNING: program timed out
ompiler exited with status 1
FAIL: gcc.c-torture/compile/20001226-1.c,  -O1


H.J.

Re: GCC 3.2 Prerelease

[Joe Buck]

HJ Lu writes:

> .../configure --enable-__cxa_atexit --enable-clocale=gnu --with-system-zlib --enable-shared --enable-threads=posix --enable-haifa --disable-checking

Many of those configure flags are just the default or should not matter.
Would any be expected to make a difference in terms of tests?

> 1. gcc 3.3 using libstdc++ from gcc 3.2. Additional failures:
> 
> +FAIL: backward/strstream_members.cc execution test
> +FAIL: gcc.c-torture/compile/20001226-1.c,  -O1  
> +FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -fomit-frame-pointer  
>
> Additonal pass:
> 
> -FAIL: 22_locale/ctype_narrow_wchar_t.cc execution test

The C failures presumably have to do with a regression in the GCC trunk
and have nothing to do with ABI issues.

Which testsuite are you using, the 3.2 one or the 3.3 one?  Or are there
no differences in the testsuite?

> 2. gcc 3.2 using libstdc++ from gcc 3.3. Additional failures:
> 
> +FAIL: 22_locale/ctype_narrow_wchar_t.cc execution test
> +FAIL: Thread_Interrupt output from bytecode->native test
> +FAIL: Thread_Wait_2 execution from bytecode->native test
> +FAIL: Thread_Wait -O execution from source compiled test

The latter three are Java failures, right?  That gives us only two
extra libstdc++ failures, one in each direction.  Could you (HJ) post
more information on what the failure is in

FAIL: backward/strstream_members.cc execution test

from part 1, and

FAIL: 22_locale/ctype_narrow_wchar_t.cc execution test

in part 2?

Thanks.

Re: GCC 3.2 Prerelease

[Joe Buck]

> > 1. gcc 3.3 using libstdc++ from gcc 3.2. Additional failures:
> >
> > +FAIL: backward/strstream_members.cc execution test
> > +FAIL: gcc.c-torture/compile/20001226-1.c,  -O1
> > +FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -fomit-frame-pointer
> 
> Here, you are claiming that changing the C++ library broke the C
> compiler.  Are you sure about that?

Which test suite is being used, and which results are being diff'd
against?  If he's comparing against 3.2 results, he may be detecting
a regression in 3.3 vs 3.2 for the C compiler.

Re: GCC 3.2 Prerelease

[Graham Stott]

Mark Mitchell wrote:

Re: GCC 3.2 Prerelease

[Neil Booth]

H. J. Lu wrote:-

> > Here, you are claiming that changing the C++ library broke the C
> > compiler.  Are you sure about that?
> 
> I got
> 
> WARNING: program timed out
> ompiler exited with status 1
> FAIL: gcc.c-torture/compile/20001226-1.c,  -O1

That just shows you that one compiler is slower than the other.  That's
the ridiculoulsy big set of labels test IIRC.

Neil.

Re: GCC 3.2 Prerelease

[H. J. Lu]

On Tue, Aug 06, 2002 at 11:42:51AM -0700, Joe Buck wrote:
> 
> > > 1. gcc 3.3 using libstdc++ from gcc 3.2. Additional failures:
> > >
> > > +FAIL: backward/strstream_members.cc execution test
> > > +FAIL: gcc.c-torture/compile/20001226-1.c,  -O1
> > > +FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -fomit-frame-pointer
> > 
> > Here, you are claiming that changing the C++ library broke the C
> > compiler.  Are you sure about that?
> 
> Which test suite is being used, and which results are being diff'd
> against?  If he's comparing against 3.2 results, he may be detecting
> a regression in 3.3 vs 3.2 for the C compiler.

I tested gcc 3.3 in gcc 3.3 test suite and 3.2 in 3.2 test suite.


H.J.

Re: GCC 3.2 Prerelease

[H. J. Lu]

On Tue, Aug 06, 2002 at 11:37:00AM -0700, Joe Buck wrote:
> 
> FAIL: backward/strstream_members.cc execution test
> 

gcc 3.3 with libstdc++.so.5.0.0 from gcc 3.2, I got

Program received signal SIGSEGV, Segmentation fault.
0x4207ad2d in free () from /lib/i686/libc.so.6
(gdb) bt
#0  0x4207ad2d in free () from /lib/i686/libc.so.6
#1  0x4009f923 in operator delete(void*) (ptr=0x8000000)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
#2  0x4009f97f in operator delete[](void*) (ptr=0x8000000)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_opv.cc:36
#3  0x400545a9 in std::strstreambuf::_M_free(char*) (this=0x8000000, 
    p=0x8049c20 "")
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:325
#4  0x40053e10 in ~strstreambuf (this=0xbffff604)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:126
#5  0x400554fc in ~ostrstream (this=0xbffff600)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:380
#6  0x080488f5 in test02() ()
    at
/home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_members.cc:41
#7  0x08048918 in main ()
    at
/home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_members.cc:47
#8  0x420175c9 in __libc_start_main () from /lib/i686/libc.so.6

After I set MALLOC_CHECK_=1, I got

free(): invalid pointer 0x8049c20!

Using libstdc++.so.5.0.0 from gcc 3.3, it ran fine.


H.J.

Re: GCC 3.2 Prerelease

[H. J. Lu]

On Tue, Aug 06, 2002 at 11:59:55AM -0700, H. J. Lu wrote:
> On Tue, Aug 06, 2002 at 11:37:00AM -0700, Joe Buck wrote:
> > 
> > FAIL: backward/strstream_members.cc execution test
> > 
> 
> gcc 3.3 with libstdc++.so.5.0.0 from gcc 3.2, I got
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x4207ad2d in free () from /lib/i686/libc.so.6
> (gdb) bt
> #0  0x4207ad2d in free () from /lib/i686/libc.so.6
> #1  0x4009f923 in operator delete(void*) (ptr=0x8000000)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
> #2  0x4009f97f in operator delete[](void*) (ptr=0x8000000)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_opv.cc:36
> #3  0x400545a9 in std::strstreambuf::_M_free(char*) (this=0x8000000, 
>     p=0x8049c20 "")
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:325
> #4  0x40053e10 in ~strstreambuf (this=0xbffff604)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:126
> #5  0x400554fc in ~ostrstream (this=0xbffff600)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:380
> #6  0x080488f5 in test02() ()
>     at
> /home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_members.cc:41
> #7  0x08048918 in main ()
>     at
> /home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_members.cc:47
> #8  0x420175c9 in __libc_start_main () from /lib/i686/libc.so.6
> 
> After I set MALLOC_CHECK_=1, I got
> 
> free(): invalid pointer 0x8049c20!
> 
> Using libstdc++.so.5.0.0 from gcc 3.3, it ran fine.

I think the same memory got freed twice. The firt time:

Breakpoint 5, operator delete(void*) (ptr=0x8049c80)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
39          free (ptr);
(gdb) bt
#0  operator delete(void*) (ptr=0x8049c80)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
#1  0x400a197f in operator delete[](void*) (ptr=0x8049c80)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_opv.cc:36
#2  0x08048907 in test02() ()
    at
/home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_members.cc:41
#3  0x08048968 in main ()
    at
/home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_members.cc:47
#4  0x40120b88 in __libc_start_main (main=0x804894e <main>, argc=1, 
    ubp_av=0xbffff764, init=0x804861c <_init>, fini=0x80489a0 <_fini>, 
    rtld_fini=0x4000ba94 <_dl_fini>, stack_end=0xbffff75c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) c

The second time:

Breakpoint 5, operator delete(void*) (ptr=0x8049c80)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
39          free (ptr);
(gdb) bt
#0  operator delete(void*) (ptr=0x8049c80)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
#1  0x400a197f in operator delete[](void*) (ptr=0x8049c80)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_opv.cc:36
#2  0x400565a9 in std::strstreambuf::_M_free(char*) (this=0x8049c80, 
    p=0x8049c80 "")
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:325
#3  0x40055e10 in ~strstreambuf (this=0xbffff5f4)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:126
#4  0x400574fc in ~ostrstream (this=0xbffff5f0)
    at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:380
#5  0x08048945 in test02() ()
    at
/home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_
members.cc:41
#6  0x08048968 in main ()
    at
/home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_
members.cc:47
#7  0x40120b88 in __libc_start_main (main=0x804894e <main>, argc=1, 
    ubp_av=0xbffff764, init=0x804861c <_init>, fini=0x80489a0 <_fini>, 
    rtld_fini=0x4000ba94 <_dl_fini>, stack_end=0xbffff75c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 

I don't know if it is a compiler/library or ABI issue. It looks strange
to me:

int test02()
{
  std::ostrstream buf;
  buf << std::ends;
  char *s = buf.str ();
  delete [] s;
}

`s' has been deleted by test02. But strstreambuf::~strstreambuf does
it again. That is in gcc 3.2.


H.J.


H.J.

Re: GCC 3.2 Prerelease

[H. J. Lu]

On Tue, Aug 06, 2002 at 12:15:01PM -0700, H. J. Lu wrote:
> On Tue, Aug 06, 2002 at 11:59:55AM -0700, H. J. Lu wrote:
> > On Tue, Aug 06, 2002 at 11:37:00AM -0700, Joe Buck wrote:
> > > 
> > > FAIL: backward/strstream_members.cc execution test
> > > 
> > 
> > gcc 3.3 with libstdc++.so.5.0.0 from gcc 3.2, I got
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x4207ad2d in free () from /lib/i686/libc.so.6
> > (gdb) bt
> > #0  0x4207ad2d in free () from /lib/i686/libc.so.6
> > #1  0x4009f923 in operator delete(void*) (ptr=0x8000000)
> >     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
> > #2  0x4009f97f in operator delete[](void*) (ptr=0x8000000)
> >     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_opv.cc:36
> > #3  0x400545a9 in std::strstreambuf::_M_free(char*) (this=0x8000000, 
> >     p=0x8049c20 "")
> >     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:325
> > #4  0x40053e10 in ~strstreambuf (this=0xbffff604)
> >     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:126
> > #5  0x400554fc in ~ostrstream (this=0xbffff600)
> >     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:380
> > #6  0x080488f5 in test02() ()
> >     at
> > /home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_members.cc:41
> > #7  0x08048918 in main ()
> >     at
> > /home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_members.cc:47
> > #8  0x420175c9 in __libc_start_main () from /lib/i686/libc.so.6
> > 
> > After I set MALLOC_CHECK_=1, I got
> > 
> > free(): invalid pointer 0x8049c20!
> > 
> > Using libstdc++.so.5.0.0 from gcc 3.3, it ran fine.
> 
> I think the same memory got freed twice. The firt time:
> 
> Breakpoint 5, operator delete(void*) (ptr=0x8049c80)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
> 39          free (ptr);
> (gdb) bt
> #0  operator delete(void*) (ptr=0x8049c80)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
> #1  0x400a197f in operator delete[](void*) (ptr=0x8049c80)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_opv.cc:36
> #2  0x08048907 in test02() ()
>     at
> /home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_members.cc:41
> #3  0x08048968 in main ()
>     at
> /home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_members.cc:47
> #4  0x40120b88 in __libc_start_main (main=0x804894e <main>, argc=1, 
>     ubp_av=0xbffff764, init=0x804861c <_init>, fini=0x80489a0 <_fini>, 
>     rtld_fini=0x4000ba94 <_dl_fini>, stack_end=0xbffff75c)
>     at ../sysdeps/generic/libc-start.c:129
> (gdb) c
> 
> The second time:
> 
> Breakpoint 5, operator delete(void*) (ptr=0x8049c80)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
> 39          free (ptr);
> (gdb) bt
> #0  operator delete(void*) (ptr=0x8049c80)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_op.cc:39
> #1  0x400a197f in operator delete[](void*) (ptr=0x8049c80)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/libsupc++/del_opv.cc:36
> #2  0x400565a9 in std::strstreambuf::_M_free(char*) (this=0x8049c80, 
>     p=0x8049c80 "")
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:325
> #3  0x40055e10 in ~strstreambuf (this=0xbffff5f4)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:126
> #4  0x400574fc in ~ostrstream (this=0xbffff5f0)
>     at /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/src/strstream.cc:380
> #5  0x08048945 in test02() ()
>     at
> /home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_
> members.cc:41
> #6  0x08048968 in main ()
>     at
> /home/hjl/work/gnu/src/gcc/gcc/libstdc++-v3/testsuite/backward/strstream_
> members.cc:47
> #7  0x40120b88 in __libc_start_main (main=0x804894e <main>, argc=1, 
>     ubp_av=0xbffff764, init=0x804861c <_init>, fini=0x80489a0 <_fini>, 
>     rtld_fini=0x4000ba94 <_dl_fini>, stack_end=0xbffff75c)
>     at ../sysdeps/generic/libc-start.c:129
> (gdb) 
> 
> I don't know if it is a compiler/library or ABI issue. It looks strange
> to me:
> 
> int test02()
> {
>   std::ostrstream buf;
>   buf << std::ends;
>   char *s = buf.str ();
>   delete [] s;
> }
> 
> `s' has been deleted by test02. But strstreambuf::~strstreambuf does
> it again. That is in gcc 3.2.
> 
> 

I looked at the code. API for strstreambuf is different between 3.2 and
3.3.


H.J.

Re: GCC 3.2 Prerelease

[H. J. Lu]

On Tue, Aug 06, 2002 at 11:37:00AM -0700, Joe Buck wrote:
> 
> FAIL: 22_locale/ctype_narrow_wchar_t.cc execution test

I got

Program received signal SIGSEGV, Segmentation fault.
0x4018940f in __wmemcpy (s1=0x40227048, s2=0xeff69520, n=100894740)
    at wmemcpy.c:30
30        return (wchar_t *) memcpy ((char *) s1, (char *) s2, n * sizeof
(wchar_t));
(gdb) bt
#0  0x4018940f in __wmemcpy (s1=0x40227048, s2=0xeff69520, n=100894740)
    at wmemcpy.c:30
#1  0x4009f761 in std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::all
ocator<wchar_t> >::_M_mutate(unsigned, unsigned, unsigned) (this=0xbffff690, 
    __pos=7, __len1=3221222784, __len2=6)
    at
/export/build/gnu/gcc/build-i686-rearden-linux/i686-pc-linux-gnu/libstdc+
+-v3/include/bits/char_traits.h:220
#2  0x400a389a in std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::all
ocator<wchar_t> >& std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::al
locator<wchar_t> >::_M_replace_safe<wchar_t
const*>(__gnu_cxx::__normal_iterator
<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::allocator<
wchar_t> > >, __gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, 
std::char_traits<wchar_t>, std::allocator<wchar_t> > >, wchar_t const*,
__gnu_cx
x::__normal_iterator<wchar_t*, std::basic_string<wchar_t,
std::char_traits<wchar
_t>, std::allocator<wchar_t> > >) (this=0xbffff690, __k1=0x80498c4, 
    __k2=0x80498dc)
    at
/export/build/gnu/gcc/build-i686-rearden-linux/i686-pc-linux-gnu/libstdc+
+-v3/include/bits/basic_string.tcc:533
#3  0x400a10e7 in std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::all
ocator<wchar_t> >::append(wchar_t const*, unsigned) (this=0x7, __s=0x80498c4, 
    __n=6)
    at
/export/build/gnu/gcc/build-i686-rearden-linux/i686-pc-linux-gnu/libstdc+
+-v3/include/bits/basic_string.tcc:596
#4  0x400a0e65 in std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::all
ocator<wchar_t> >::operator+=(wchar_t const*) (this=0x6038814, __s=0x6)
    at
/export/build/gnu/gcc/build-i686-rearden-linux/i686-pc-linux-gnu/libstdc+
+-v3/include/bits/char_traits.h:208
#5  0x08049085 in test02() ()
    at
/home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/testsuite/22_locale/ctype
_narrow_wchar_t.cc:79
#6  0x08049376 in main ()
    at
/home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/testsuite/22_locale/ctype
_narrow_wchar_t.cc:104
#7  0x40124b88 in __libc_start_main (main=0x804935c <main>, argc=1, 
---Type <return> to continue, or q <return> to quit---
    ubp_av=0xbffff754, init=0x804894c <_init>, fini=0x8049790 <_fini>, 
    rtld_fini=0x4000ba94 <_dl_fini>, stack_end=0xbffff74c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) p s1
$1 = (wchar_t *) 0x40227048
(gdb) p *s1
$2 = 0
(gdb) p s2
$3 = (wchar_t *) 0xeff69520
(gdb) p *s2
Cannot access memory at address 0xeff69520

It may be a compiler/library bug.

H.J.

Re: GCC 3.2 Prerelease

[David Edelsohn]

>>>>> H J Lu writes:

HJ> I looked at the code. API for strstreambuf is different between 3.2 and
HJ> 3.3.

	The strstream reversion patch is "queued" for 3.2.1. 

http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00188.html

David

Re: GCC 3.2 Prerelease

[H. J. Lu]

On Tue, Aug 06, 2002 at 12:24:32PM -0700, H. J. Lu wrote:
> On Tue, Aug 06, 2002 at 11:37:00AM -0700, Joe Buck wrote:
> > 
> > FAIL: 22_locale/ctype_narrow_wchar_t.cc execution test
> 
> I got
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x4018940f in __wmemcpy (s1=0x40227048, s2=0xeff69520, n=100894740)
>     at wmemcpy.c:30
> 30        return (wchar_t *) memcpy ((char *) s1, (char *) s2, n * sizeof
> (wchar_t));
> (gdb) bt
> #0  0x4018940f in __wmemcpy (s1=0x40227048, s2=0xeff69520, n=100894740)
>     at wmemcpy.c:30
> #1  0x4009f761 in std::basic_string<wchar_t, std::char_traits<wchar_t>,
> std::all
> ocator<wchar_t> >::_M_mutate(unsigned, unsigned, unsigned) (this=0xbffff690, 
>     __pos=7, __len1=3221222784, __len2=6)
>     at
> /export/build/gnu/gcc/build-i686-rearden-linux/i686-pc-linux-gnu/libstdc+
> +-v3/include/bits/char_traits.h:220
> #2  0x400a389a in std::basic_string<wchar_t, std::char_traits<wchar_t>,
> std::all
> ocator<wchar_t> >& std::basic_string<wchar_t, std::char_traits<wchar_t>,
> std::al
> locator<wchar_t> >::_M_replace_safe<wchar_t
> const*>(__gnu_cxx::__normal_iterator
> <wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>,
> std::allocator<
> wchar_t> > >, __gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, 
> std::char_traits<wchar_t>, std::allocator<wchar_t> > >, wchar_t const*,
> __gnu_cx
> x::__normal_iterator<wchar_t*, std::basic_string<wchar_t,
> std::char_traits<wchar
> _t>, std::allocator<wchar_t> > >) (this=0xbffff690, __k1=0x80498c4, 
>     __k2=0x80498dc)
>     at
> /export/build/gnu/gcc/build-i686-rearden-linux/i686-pc-linux-gnu/libstdc+
> +-v3/include/bits/basic_string.tcc:533
> #3  0x400a10e7 in std::basic_string<wchar_t, std::char_traits<wchar_t>,
> std::all
> ocator<wchar_t> >::append(wchar_t const*, unsigned) (this=0x7, __s=0x80498c4, 
>     __n=6)
>     at
> /export/build/gnu/gcc/build-i686-rearden-linux/i686-pc-linux-gnu/libstdc+
> +-v3/include/bits/basic_string.tcc:596
> #4  0x400a0e65 in std::basic_string<wchar_t, std::char_traits<wchar_t>,
> std::all
> ocator<wchar_t> >::operator+=(wchar_t const*) (this=0x6038814, __s=0x6)
>     at
> /export/build/gnu/gcc/build-i686-rearden-linux/i686-pc-linux-gnu/libstdc+
> +-v3/include/bits/char_traits.h:208
> #5  0x08049085 in test02() ()
>     at
> /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/testsuite/22_locale/ctype
> _narrow_wchar_t.cc:79
> #6  0x08049376 in main ()
>     at
> /home/hjl/work/gnu/src/gcc-3.2/gcc/libstdc++-v3/testsuite/22_locale/ctype
> _narrow_wchar_t.cc:104
> #7  0x40124b88 in __libc_start_main (main=0x804935c <main>, argc=1, 
> ---Type <return> to continue, or q <return> to quit---
>     ubp_av=0xbffff754, init=0x804894c <_init>, fini=0x8049790 <_fini>, 
>     rtld_fini=0x4000ba94 <_dl_fini>, stack_end=0xbffff74c)
>     at ../sysdeps/generic/libc-start.c:129
> (gdb) p s1
> $1 = (wchar_t *) 0x40227048
> (gdb) p *s1
> $2 = 0
> (gdb) p s2
> $3 = (wchar_t *) 0xeff69520
> (gdb) p *s2
> Cannot access memory at address 0xeff69520
> 
> It may be a compiler/library bug.

It may be a bug in gcc 3.3 since it fails with libstdc++ from gcc 3.3
and passes with libstdc++ from gcc 3.2.


H.J.

Re: GCC 3.2 Prerelease

[Joe Buck]

> >>>>> H J Lu writes:
> 
> HJ> I looked at the code. API for strstreambuf is different between 3.2 and
> HJ> 3.3.
> 
> 	The strstream reversion patch is "queued" for 3.2.1. 
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00188.html

It seems that this is the only issue that anyone has identified that
indicates a 3.2/3.3 ABI incompatibility (as opposed to a regression or
test issue).  If so, maybe this patch should go into 3.2.  (Mark, I know
you've already done a prerelease, sorry to reopen but since ABI stability
is a main goal it might be worth doing if this is the only one).

Re: GCC 3.2 Prerelease

[Mark Mitchell]

--On Tuesday, August 06, 2002 02:14:16 PM -0700 Joe Buck 
<Joe.Buck@synopsys.com> wrote:

Re: GCC 3.2 Prerelease

[B. Kosnik]

> Benjamin, would you put this in please ASAP and let me know when it is
> done?

Done.

Re: GCC 3.2 Prerelease

[Phil Edwards]

On Tue, Aug 06, 2002 at 01:10:24PM -0400, Phil Edwards wrote:
> On Mon, Aug 05, 2002 at 06:07:25PM -0700, B. Kosnik wrote:
> > There are 155 g++ fails, and 15 libstdc++ fails, when the 3.3
> > libstdc++.so is used with the 3.2 toolchain.
> 
> I'm finally far enough recovered from a fatal hard drive crash that I can
> try and do this test today.

Took longer than I thought.

For me, when the 3.2 libstdc++.so is used with the 3.3 compiler, I see

    fenric 27% diff results-3.2 results-3.3
    29d28
    < FAIL: backward/strstream_members.cc execution test
    33,34c32,33
    < # of expected passes          414
    < # of unexpected failures      3
    ---
    > # of expected passes          415
    > # of unexpected failures      2
    fenric 28%

the expected failure.

When the 3.3 libstdc++.so is used with the 3.2 compiler, I see no differences
at all.  Huh.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

GCC 3.2 Prerelease

[Mark Mitchell]

The current GCC 3.2 Prerelease is available at:

 ftp://gcc.gnu.org/pub/gcc/snapshots/

The files all have "3.2-20020809" in their names.

Please test these tarballs for packaging and buildability.

Barring disaster, these sources will become the 3.2 release on
Wednesday, August 14.

Thanks,

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

GCC 3.2 Prerelease

[Mark Mitchell]

I'm planning on spinning the GCC 3.2 prerelease in 24 hours -- are there
any more patches for which people think we need to hold up this release?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com