Re: alpha bootstrap failure, new symptom

Re: alpha bootstrap failure, new symptom

[Richard Kenner]

    When I said "make bootstrap" it failed.  I presume that it would have
    done the same for you, since the problem seems to have been
    machine-independent.

When I do "make bootstrap", it just bootstraps the compiler.  Perhaps you
were in the directory above "gcc" when you did it.  That might also build
other stuff (which I never got working for me).

Re: alpha bootstrap failure, new symptom

[Brad Lucier]

> 
>     When I said "make bootstrap" it failed.  I presume that it would have
>     done the same for you, since the problem seems to have been
>     machine-independent.
> 
> When I do "make bootstrap", it just bootstraps the compiler.  Perhaps you
> were in the directory above "gcc" when you did it.  That might also build
> other stuff (which I never got working for me).

I do, basically,

cvs -z 9 co gcc
cd gcc
mkdir objdir
cd objdir
../configure --enable-languages='c,c++,java,objc,f77'
make -j 4 bootstrap >& build.log

Only I usually use a slightly hacked (to also update new directories)
contrib/gcc_update to keep the gcc directory updated.

I've understood that this is how to build the compiler to test it.
And that has always worked (modulo parallel build bugs).

Brad

Re: alpha bootstrap failure, new symptom

[Brad Lucier]

> 
>     When I said "make bootstrap" it failed.  I presume that it would have
>     done the same for you, since the problem seems to have been
>     machine-independent.
> 
> When I do "make bootstrap", it just bootstraps the compiler.  Perhaps you
> were in the directory above "gcc" when you did it.  That might also build
> other stuff (which I never got working for me).

I do, basically,

cvs -z 9 co gcc
cd gcc
mkdir objdir
cd objdir
../configure --enable-languages='c,c++,java,objc,f77'
make -j 4 bootstrap >& build.log

Only I usually use a slightly hacked (to also update new directories)
contrib/gcc_update to keep the gcc directory updated.

I've understood that this is how to build the compiler to test it.
And that has always worked (modulo parallel build bugs).

Brad

Re: alpha bootstrap failure, new symptom

[Mark Mitchell]

--On Wednesday, November 28, 2001 12:37:58 PM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     When I said "make bootstrap" it failed.  I presume that it would have
>     done the same for you, since the problem seems to have been
>     machine-independent.
>
> When I do "make bootstrap", it just bootstraps the compiler.  Perhaps you
> were in the directory above "gcc" when you did it.  That might also build
> other stuff (which I never got working for me).

It sounds like you are still not following our testing procedures.  Once
again, all checkins to language-independent code should be proceeded by

  make bootstrap
  make check

at the top level, and there should be no new tests.  You must rebuild
all libraries as part of your testing process.

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

Re: alpha bootstrap failure, new symptom

[Mark Mitchell]

--On Wednesday, November 28, 2001 12:37:58 PM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     When I said "make bootstrap" it failed.  I presume that it would have
>     done the same for you, since the problem seems to have been
>     machine-independent.
>
> When I do "make bootstrap", it just bootstraps the compiler.  Perhaps you
> were in the directory above "gcc" when you did it.  That might also build
> other stuff (which I never got working for me).

It sounds like you are still not following our testing procedures.  Once
again, all checkins to language-independent code should be proceeded by

  make bootstrap
  make check

at the top level, and there should be no new tests.  You must rebuild
all libraries as part of your testing process.

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

Re: alpha bootstrap failure, new symptom

[Richard Kenner]

    When I said "make bootstrap" it failed.  I presume that it would have
    done the same for you, since the problem seems to have been
    machine-independent.

When I do "make bootstrap", it just bootstraps the compiler.  Perhaps you
were in the directory above "gcc" when you did it.  That might also build
other stuff (which I never got working for me).

Re: alpha bootstrap failure, new symptom

[Richard Kenner]

    I know that Richard Henderson uses an Alpha box every day, and has no
    trouble this way.

He uses Alpha/Linux, I use Alpha/OSF, which is a big difference.

    I'm sure that people will help you.

Last time I sent messages about it, nobody was able to figure it out, but
I can try again.

I suspect it's some old relic somewhere in the machine.  We're planning on
replacing it soon, so it'll probably go away then.

Re: alpha bootstrap failure, new symptom

[Richard Kenner]

    I know that Richard Henderson uses an Alpha box every day, and has no
    trouble this way.

He uses Alpha/Linux, I use Alpha/OSF, which is a big difference.

    I'm sure that people will help you.

Last time I sent messages about it, nobody was able to figure it out, but
I can try again.

I suspect it's some old relic somewhere in the machine.  We're planning on
replacing it soon, so it'll probably go away then.

Re: alpha bootstrap failure, new symptom

[Richard Kenner]

    It sounds like you are still not following our testing procedures.  Once
    again, all checkins to language-independent code should be proceeded by

      make bootstrap
      make check

    at the top level, and there should be no new tests.

I always work at the the level of the GCC subdirectory and the "make compare"
and "make gnatlib_and_tools" between those.  I was unaware that there was an
important distinction here and the web pages weren't clear until today.

I have always viewed the top level stuff as a morass and have never gotten
anything to work at that level.  I always get bizarre errors that nobody
is able to figure out and I think configure claims that at least one of
them isn't even supported on my configuration.

Re: alpha bootstrap failure, new symptom

[Aldy Hernandez]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

 >     It sounds like you are still not following our testing procedures.  Once
 >     again, all checkins to language-independent code should be proceeded by

 >       make bootstrap
 >       make check

 >     at the top level, and there should be no new tests.

 > I always work at the the level of the GCC subdirectory and the "make compare"
 > and "make gnatlib_and_tools" between those.  I was unaware that there was an
 > important distinction here and the web pages weren't clear until today.

 > I have always viewed the top level stuff as a morass and have never gotten
 > anything to work at that level.  I always get bizarre errors that nobody
 > is able to figure out and I think configure claims that at least one of
 > them isn't even supported on my configuration.

If it's such a pain, use a combined tree, which is already packaged in:

cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/uberbaum login
cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/uberbaum checkout .

Pretty cool, and you get binutils, sim, gcc, etc.  Everything in one
and you can do a toplevel configure, make, whatever.

Aldy

Re: alpha bootstrap failure, new symptom

[Aldy Hernandez]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

 >     It sounds like you are still not following our testing procedures.  Once
 >     again, all checkins to language-independent code should be proceeded by

 >       make bootstrap
 >       make check

 >     at the top level, and there should be no new tests.

 > I always work at the the level of the GCC subdirectory and the "make compare"
 > and "make gnatlib_and_tools" between those.  I was unaware that there was an
 > important distinction here and the web pages weren't clear until today.

 > I have always viewed the top level stuff as a morass and have never gotten
 > anything to work at that level.  I always get bizarre errors that nobody
 > is able to figure out and I think configure claims that at least one of
 > them isn't even supported on my configuration.

If it's such a pain, use a combined tree, which is already packaged in:

cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/uberbaum login
cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/uberbaum checkout .

Pretty cool, and you get binutils, sim, gcc, etc.  Everything in one
and you can do a toplevel configure, make, whatever.

Aldy

Re: alpha bootstrap failure, new symptom

[Mark Mitchell]

> I have always viewed the top level stuff as a morass and have never gotten
> anything to work at that level.  I always get bizarre errors that nobody
> is able to figure out and I think configure claims that at least one of
> them isn't even supported on my configuration.

It works for most everyone else pretty easily.  I know that Richard
Henderson uses an Alpha box every day, and has no trouble this way.

You really need to resolve this before you make more checkins.

I'm sure that people will help you.

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

Re: alpha bootstrap failure, new symptom

[Mark Mitchell]

> I have always viewed the top level stuff as a morass and have never gotten
> anything to work at that level.  I always get bizarre errors that nobody
> is able to figure out and I think configure claims that at least one of
> them isn't even supported on my configuration.

It works for most everyone else pretty easily.  I know that Richard
Henderson uses an Alpha box every day, and has no trouble this way.

You really need to resolve this before you make more checkins.

I'm sure that people will help you.

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

Re: alpha bootstrap failure, new symptom

[Richard Kenner]

    It sounds like you are still not following our testing procedures.  Once
    again, all checkins to language-independent code should be proceeded by

      make bootstrap
      make check

    at the top level, and there should be no new tests.

I always work at the the level of the GCC subdirectory and the "make compare"
and "make gnatlib_and_tools" between those.  I was unaware that there was an
important distinction here and the web pages weren't clear until today.

I have always viewed the top level stuff as a morass and have never gotten
anything to work at that level.  I always get bizarre errors that nobody
is able to figure out and I think configure claims that at least one of
them isn't even supported on my configuration.

Re: alpha bootstrap failure, new symptom

[Richard Kenner]

That's not a bootstrap failure, but a failure building libstdc++.

I checked in the fix for that about an hour ago.

Re: alpha bootstrap failure, new symptom

[Brad Lucier]

> That's not a bootstrap failure, but a failure building libstdc++.

Well, OK.  When I said "make bootstrap" it failed.  I presume that
it would have done the same for you, since the problem seems to have
been machine-independent.

> I checked in the fix for that about an hour ago.

Yes, I found it, thanks.

Brad

Re: alpha bootstrap failure, new symptom

[Brad Lucier]

> That's not a bootstrap failure, but a failure building libstdc++.

Well, OK.  When I said "make bootstrap" it failed.  I presume that
it would have done the same for you, since the problem seems to have
been machine-independent.

> I checked in the fix for that about an hour ago.

Yes, I found it, thanks.

Brad

Re: alpha bootstrap failure, new symptom

[Richard Kenner]

That's not a bootstrap failure, but a failure building libstdc++.

I checked in the fix for that about an hour ago.

alpha bootstrap failure, new symptom

[Brad Lucier]

After a generic configure (without ada) bootstrap fails on 
alphaev6-unknown-linux-gnu after a good compare with

/export/u11/lucier/programs/gcc/gcc-3.1/objdir/gcc/xgcc -B/export/u11/lucier/programs/gcc/gcc-3.1/objdir/gcc/ -nostdinc++ -L/export/u11/lucier/programs/gcc/gcc-3.1/objdir/alphaev6-unknown-linux-gnu/libstdc++-v3/src -L/export/u11/lucier/programs/gcc/gcc-3.1/objdir/alphaev6-unknown-linux-gnu/libstdc++-v3/src/.libs -B/export/u10/gcc-3.1-test/alphaev6-unknown-linux-gnu/bin/ -B/export/u10/gcc-3.1-test/alphaev6-unknown-linux-gnu/lib/ -isystem /export/u10/gcc-3.1-test/alphaev6-unknown-linux-gnu/include -I../../../../libstdc++-v3/../gcc -I../../../../libstdc++-v3/../include -I/export/u11/lucier/programs/gcc/gcc-3.1/objdir/alphaev6-unknown-linux-gnu/libstdc++-v3/include/alphaev6-unknown-linux-gnu -I/export/u11/lucier/programs/gcc/gcc-3.1/objdir/alphaev6-unknown-linux-gnu/libstdc++-v3/include -I../../../../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -mieee -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-!
sections -g -c ../../../../libstdc++-v3/libsupc++/del_op.cc  -fPIC -DPIC -o del_op.o
In file included from ../../../../libstdc++-v3/libsupc++/new:41,
                 from ../../../../libstdc++-v3/libsupc++/del_op.cc:31:
../../../../libstdc++-v3/libsupc++/exception:62: Tree check: expected tree_list
   , have tree_vec in xref_basetypes, at cp/decl.c:12947

Brad

alpha bootstrap failure, new symptom

[Brad Lucier]

After a generic configure (without ada) bootstrap fails on 
alphaev6-unknown-linux-gnu after a good compare with

/export/u11/lucier/programs/gcc/gcc-3.1/objdir/gcc/xgcc -B/export/u11/lucier/programs/gcc/gcc-3.1/objdir/gcc/ -nostdinc++ -L/export/u11/lucier/programs/gcc/gcc-3.1/objdir/alphaev6-unknown-linux-gnu/libstdc++-v3/src -L/export/u11/lucier/programs/gcc/gcc-3.1/objdir/alphaev6-unknown-linux-gnu/libstdc++-v3/src/.libs -B/export/u10/gcc-3.1-test/alphaev6-unknown-linux-gnu/bin/ -B/export/u10/gcc-3.1-test/alphaev6-unknown-linux-gnu/lib/ -isystem /export/u10/gcc-3.1-test/alphaev6-unknown-linux-gnu/include -I../../../../libstdc++-v3/../gcc -I../../../../libstdc++-v3/../include -I/export/u11/lucier/programs/gcc/gcc-3.1/objdir/alphaev6-unknown-linux-gnu/libstdc++-v3/include/alphaev6-unknown-linux-gnu -I/export/u11/lucier/programs/gcc/gcc-3.1/objdir/alphaev6-unknown-linux-gnu/libstdc++-v3/include -I../../../../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -mieee -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-!
sections -g -c ../../../../libstdc++-v3/libsupc++/del_op.cc  -fPIC -DPIC -o del_op.o
In file included from ../../../../libstdc++-v3/libsupc++/new:41,
                 from ../../../../libstdc++-v3/libsupc++/del_op.cc:31:
../../../../libstdc++-v3/libsupc++/exception:62: Tree check: expected tree_list
   , have tree_vec in xref_basetypes, at cp/decl.c:12947

Brad