Re: egcs-ss-970814

Re: egcs-ss-970814

[H.J. Lu]

> The more I think about it, the more I feel there should be a "full blown"
> release -- with all the languages, testsuites, targets, etc and a "lite"
> release which is just the C compiler, then separate tarballs released in
> lockstep that one can extract to get g++, g77, objc, the testsuite, etc.
> 

Should I dig out my libgccbackend.so patch? It will reduce the binary
size:

# ls -l /usr/lib/gcc-lib/i486-linux/2.7.2-951223-so
-rwxr-xr-x   1 root     root       204648 Dec 23  1995 cc1
-rwxr-xr-x   1 root     root       281244 Dec 23  1995 cc1obj
-rwxr-xr-x   1 root     root       608308 Dec 23  1995 cc1plus
-rwxr-xr-x   1 root     root      1470404 Dec 23  1995 libgccbnd.so.2.7.2-951223-so


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: 970814 and libg++

[Mumit Khan]

hjl@lucon.org (H.J. Lu) writes:
> > 
> > btw, static template data members are not being instantiated breaking SGI
> > STL in libg++-2.8.0b6 (the allocator in particular). Also, I'm getting a 
> > core dump when compiling libstdc++ tests when compiling with '-g -O2', but 
> > with -g. Anybody else seen this? This is on a hppa1.1-hp-hpux10.20 using 
> > GAS from binutils 2.8.1. I'll investigate this further on other platforms.
> > 
> 
> Same here on Linux/x86.

Just tried i386-linux-gnulibc1 and static template data *is* being
instantiated! The core dump however remains whenever -O is used for
libstdc++/test/tmap.cc.

gdb output:

===========

[khan@home] gdb tmap core
GDB is free software and you are welcome to 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.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation,
Inc...
Core was generated by `./tmap'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from
/homes/src/libg++-2.8.0/libstdc++/../libstdc++/libstdc++.so.2.8...done.
Reading symbols from /lib/libc.so.5.3.12...done.
Reading symbols from /lib/libm.so.5.0.6...done.
Reading symbols from /lib/ld-linux.so.1...done.
#0  0x804990b in rb_tree<int, pair<int const, int>, select1st<pair<int
const, int> >, int_less, __default_alloc_template<false, 0>
>::insert_unique (
    this=0xbffff3b8, v=@0xbffff358) at ../stl/tree.h:125
125             y = y->right;
(gdb) where
#0  0x804990b in rb_tree<int, pair<int const, int>, select1st<pair<int
const, int> >, int_less, __default_alloc_template<false, 0>
>::insert_unique (
    this=0xbffff3b8, v=@0xbffff358) at ../stl/tree.h:125
#1  0x8048f13 in main (argv=1, argc=0xbffff3e4) at ../stl/map.h:110
#2  0x804885b in ___crt_dummy__ ()
(gdb) print y
$1 = (__rb_tree_node_base *) 0x414c4658
(gdb) print *y
Cannot access memory at address 0x414c4658.

===========

Mumit

Re: egcs-ss-970814

[Jeffrey A Law]

  In message <m0x07Mv-0004ecC@ocean.lucon.org>you write:
  > > The more I think about it, the more I feel there should be a "full blown"
  > > release -- with all the languages, testsuites, targets, etc and a "lite"
  > > release which is just the C compiler, then separate tarballs released in
  > > lockstep that one can extract to get g++, g77, objc, the testsuite, etc.
  > > 
  > 
  > Should I dig out my libgccbackend.so patch? It will reduce the binary
  > size:
I think we should look into this as longer term issue; I think the
release packaging should take priority.

jeff

egcs-ss-970814

[David S. Miller]

Bootstrapped successfully and passed make compare (except of course
for the zzz.o file) on sparc-linux-gnulibc1 both with and without the
Haifa scheduler enabled.

Any timeframe on a initial cut of the new test suite mechanism?  I'd
like to start cranking.

Re: egcs-ss-970814

[Andi Kleen]

"David S. Miller" <davem@jenolan.rutgers.edu> writes:

> Bootstrapped successfully and passed make compare (except of course
> for the zzz.o file) on sparc-linux-gnulibc1 both with and without the
> Haifa scheduler enabled.
> 
> Any timeframe on a initial cut of the new test suite mechanism?  I'd
> like to start cranking.

I would prefer to have the test suite still in a separate tar file -
it makes working with a low-bandwidth networking connection easier.

Thanks,
-Andi

Re: egcs-ss-970814

[Jeffrey A Law]

  In message <199708162330.TAA04921@jenolan.rutgers.edu>you write:
  > 
  > Bootstrapped successfully and passed make compare (except of course
  > for the zzz.o file) on sparc-linux-gnulibc1 both with and without the
  > Haifa scheduler enabled.
Great.  Hopefully the zzz.o problem will be cleared up before the next
snapshot.

  > Any timeframe on a initial cut of the new test suite mechanism?  I'd
  > like to start cranking.
Hmmm, good question.  It'd be good to get it in asap so that it could be
used for testing before the Aug/Sept release -- even if it's just the basic
dejagnu stuff without the automatic nightly testing stuff.

And (of course) the testsuite brings up another packaging issue -- whether
or not to include it in the main tarball.

The more I think about it, the more I feel there should be a "full blown"
release -- with all the languages, testsuites, targets, etc and a "lite"
release which is just the C compiler, then separate tarballs released in
lockstep that one can extract to get g++, g77, objc, the testsuite, etc.

If we can get a handle on doing releases like that, then we can think
later about what to do with the config directory.


Jeff