GCC 3.0 Branch Status

GCC 3.0 Branch Status

[Mark Mitchell]

The branch status page:

  http://gcc.gnu.org/gcc-3.0/branch.html

shows that as of last reports, we still have boostrap failures on AIX,
ARM, and HPUX.

I'm looking at AIX issues today.  Benjamin, is there any progress on
the V3 issues?

Jeff Law is working on HPUX, and is close -- but is out of town this
weekend.

I think ARM is fixed, but I don't know.  Philip?

The bottom line is that we are not yet ready to branch; we're still
seeing bootstrap failures on two of the primary platforms.  If you
have spare cycles, please try to help with these platforms, or fix
other important bugs.

Thanks to Christian, Philip, and David who have all helped test, and
to many others that have offerred.

Yours,

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

Re: GCC 3.0 Branch Status

[Philip Blundell]

>I think ARM is fixed, but I don't know.  Philip?

I ran a bootstrap last night which failed in `make compare'.  This is further 
than it was getting previously, so it looks like the recent breakage may be 
fixed.  I've started another run now with `--disable-checking' to see if that 
solves the comparison problems; I'll report back when it completes.

p.

Re: GCC 3.0 Branch Status

[Rod Stewart]

On Mon, 22 Jan 2001, Rod m. Stewart wrote:
> 
> My bootstrap has passed the previous failure without any problem now
> (with and without the option: --enble-debug).  So it looks as if the
> problem is no longer there.  I'll send a message after both builds
> finish, but there should be no real problem.

OK, my build pretty much succeeded on armv[3,4]l-unknown-linux-gnu.  Well
there are problems with Java support.  The testsuite hangs under
i386-unknown-linux-gnu and armv*-unknown-linux-gnu.  As well I'm not
certain if the Java code will build under ARM GNU/Linux.  I sent one
little fix to gcc-patches, along with what looks like a libtool problem.

Aside from the Java problem ARM GNU/Linux seems OK, I might have to kick
the auto build a bit to work around Java, but that should not be hard.

-Rms

Re: GCC 3.0 Branch Status

[Rod m. Stewart]

Richard Earnshaw wrote:
> 
> > Richard Earnshaw wrote:
> >
> > > I bootstrapped Friday's sources on my Netwinder without a problem; both
> > > with and without checking enabled.
> > >
> > > What I'm most concerned about is that the autobuild at NetWinder.org is
> > > still failing -- it seems to be showing all the hallmarks of using the
> > > pre-fixed copy of reload1.c.  Rod, can you check that it really is
> > > building from the latest sources?
> >
> > No, it has the latest reload1.c from CVS.  It seems to be dying with the
> > following error (and looking back, has for a little while).  About the
> > only major difference I have is I was building with --enable-debug.
> > I'll start a build now without that and see how it goes (although it
> > will take about 10 hours to complete).
> >
> > (My machine crashed over the weekend, so I'm just starting today's build
> > now.)
> >
> > Here is the error I've been getting:
> 
> Yes, I can see the error from the build logs.  Since I can't reproduce
> this on my own machine, I'm going to need more information.  If it fails
> again, can you get me a stack back-trace from gdb?

My bootstrap has passed the previous failure without any problem now
(with and without the option: --enble-debug).  So it looks as if the
problem is no longer there.  I'll send a message after both builds
finish, but there should be no real problem.

-Rms

Re: GCC 3.0 Branch Status

[Richard Earnshaw]

> Richard Earnshaw wrote:
> 
> > I bootstrapped Friday's sources on my Netwinder without a problem; both
> > with and without checking enabled.
> > 
> > What I'm most concerned about is that the autobuild at NetWinder.org is
> > still failing -- it seems to be showing all the hallmarks of using the
> > pre-fixed copy of reload1.c.  Rod, can you check that it really is
> > building from the latest sources?
> 
> No, it has the latest reload1.c from CVS.  It seems to be dying with the
> following error (and looking back, has for a little while).  About the
> only major difference I have is I was building with --enable-debug. 
> I'll start a build now without that and see how it goes (although it
> will take about 10 hours to complete).
> 
> (My machine crashed over the weekend, so I'm just starting today's build
> now.)
> 
> Here is the error I've been getting:

Yes, I can see the error from the build logs.  Since I can't reproduce 
this on my own machine, I'm going to need more information.  If it fails 
again, can you get me a stack back-trace from gdb?

R.

Re: GCC 3.0 Branch Status

[Rod m. Stewart]

Richard Earnshaw wrote:

> I bootstrapped Friday's sources on my Netwinder without a problem; both
> with and without checking enabled.
> 
> What I'm most concerned about is that the autobuild at NetWinder.org is
> still failing -- it seems to be showing all the hallmarks of using the
> pre-fixed copy of reload1.c.  Rod, can you check that it really is
> building from the latest sources?

No, it has the latest reload1.c from CVS.  It seems to be dying with the
following error (and looking back, has for a little while).  About the
only major difference I have is I was building with --enable-debug. 
I'll start a build now without that and see how it goes (although it
will take about 10 hours to complete).

(My machine crashed over the weekend, so I'm just starting today's build
now.)

Here is the error I've been getting:

[build@feynman gcc]$ ./xgcc -B./
-B/usr/local/armv3l-unknown-linux-gnu/bin/ -isystem
/usr/local/armv3l-unknown-linux-gnu/include  -S tmp-dum.c -v
Reading specs from ./specs
Configured with: /home/build-rpm/BUILD/gcc/configure --enable-debug
--prefix=/usr/local --enable-shared --enable-threads=posix --without-cvs
armv3l-unknown-linux-gnu
gcc version 2.97 20010118 (experimental)
 ./cc1 -lang-c -v -iprefix
./../lib/gcc-lib/armv3l-unknown-linux-gnu/2.97/ -isystem ./include
-isystem /usr/local/armv3l-unknown-linux-gnu/bin/include -D__GNUC__=2
-D__GNUC_MINOR__=97 -D__GNUC_PATCHLEVEL__=0 -Dunix -Dlinux -D__ELF__
-D__unix__ -D__linux__ -D__ELF__ -D__unix -D__linux -Asystem=unix
-Asystem=posix -Acpu=arm -Amachine=arm -D__CHAR_UNSIGNED__
-D__STDC_HOSTED__=1 -D__ARM_ARCH_3__ -D__APCS_32__ -D__ARMEL__ -D__arm__
-isystem /usr/local/armv3l-unknown-linux-gnu/include tmp-dum.c -quiet
-dumpbase tmp-dum.c -version -o tmp-dum.s
xgcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

-Rms

Re: GCC 3.0 Branch Status

[Richard Earnshaw]

> >Hmm.  I don't know what to make of that at all.
> >
> >Can you make any  progress debugging it?
> 
> Turns out it was a local screw-up.  I had an old, broken version of the linker 
> sequestered in /usr/local/armv4l-unknown-linux-gnu/bin, and this was of course 
> being picked up in preference to the (working) one in /usr/bin.  Anyway, I've 
> fixed this now and the bootstrap completed successfully.  The tests are 
> running now but they won't be done until tomorrow morning.

Bizzare.  I had exactly the same problem in reverse!  That is, my linker 
in /usr/bin was segfaulting there, but the one I had sequestered away on 
my own path was fine.  The results however, were similar -- my autobuild 
scripts used to fail, while a manual 'gnumake bootstra' was working OK.

> The "can't bootstrap without --disable-checking" syndrome still bothers me a 
> bit, but I'm completely baffled by that one.

I bootstrapped Friday's sources on my Netwinder without a problem; both 
with and without checking enabled.

What I'm most concerned about is that the autobuild at NetWinder.org is 
still failing -- it seems to be showing all the hallmarks of using the 
pre-fixed copy of reload1.c.  Rod, can you check that it really is 
building from the latest sources?

Richard.

Re: GCC 3.0 Branch Status

[Geoff Keating]

Philip Blundell <philb@gnu.org> writes:

> The "can't bootstrap without --disable-checking" syndrome still bothers me a 
> bit, but I'm completely baffled by that one.

This probably means that there's a bug, but that --disable-checking
changes the code enough so that the bug is not triggered.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC 3.0 Branch Status

[Philip Blundell]

>Hmm.  I don't know what to make of that at all.
>
>Can you make any  progress debugging it?

Turns out it was a local screw-up.  I had an old, broken version of the linker 
sequestered in /usr/local/armv4l-unknown-linux-gnu/bin, and this was of course 
being picked up in preference to the (working) one in /usr/bin.  Anyway, I've 
fixed this now and the bootstrap completed successfully.  The tests are 
running now but they won't be done until tomorrow morning.

The "can't bootstrap without --disable-checking" syndrome still bothers me a 
bit, but I'm completely baffled by that one.

p.

Re: GCC 3.0 Branch Status

[Mark Mitchell]

Hmm.  I don't know what to make of that at all.

Can you make any  progress debugging it?

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

Re: GCC 3.0 Branch Status

[Philip Blundell]

>I ran a bootstrap last night which failed in `make compare'.  This is further 
>than it was getting previously, so it looks like the recent breakage may be 
>fixed.  I've started another run now with `--disable-checking' to see if that 
>solves the comparison problems; I'll report back when it completes.

Well, this is bizarre.  The bootstrap now passes `make compare' but blows up 
here:

/home/pb/dev/gcc/objdir/gcc/xgcc -B/home/pb/dev/gcc/objdir/gcc/ -B/usr/local/armv4l-unknown-linux-gnu/bin/ -B/usr/local/armv4l-unknown-linux-gnu/lib/ -isystem /usr/local/armv4l-unknown-linux-gnu/include -shared  .libs/limitsMEMBERS.o .libs/complex_io.o .libs/stdexcept.o .libs/bitset.o .libs/c++io.o .libs/ios.o .libs/strstream.o .libs/locale.o .libs/localename.o .libs/codecvt.o .libs/locale-inst.o .libs/stl-inst.o .libs/misc-inst.o .libs/valarray-inst.o .libs/string-inst.o -Wl,--whole-archive ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive  -lm ../libmath/.libs/libmath.a -lm ../libsupc++/.libs/libsupc++convenience.a -lm -lm  -Wl,-O1 -Wl,-soname -Wl,libstdc++.so.3 -o .libs/libstdc++.so.3.0.0
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
make[4]: *** [libstdc++.la] Error 1

If I repeat that command with -v added, then copy the collect2 invocation and 
run it by hand, it completes successfully.  I don't know what's going on here.

(This is with binutils-2.10.1.0.2.)

p.