On Jan 16, 2006, [EMAIL PROTECTED] (Richard Kenner) wrote:
What it used to be make and make bootstrap are (and will be)
./configure --disable-bootstrap make and ./configure make.
Rerunning configure is a pain! It's never just ./configure, but
has the source directory plus any
Fourth, because toplevel bootstrap is a prerequisite for many further
cleanups and improvements, including moving libgcc to the toplevel and
bootstrapping libada.
For my information, what point is there in boostrapping libada ?
BTW, it seems that ADAFLAGS (and BOOT_ADAFLAGS) are no longer
We already do sort of bootstrap libada by including some rts routines
in the compiler.
Right, because those are explicitly listed in the compiler's Makefile
and are part of the compiler.
It would be possible to do so by really building libada three times,
rather than by using
I see it as impossible with the old bootstrapping mechanism as being
for a good reason: it's not part of the compiler! I still fail to understand
what it means to bootstrap anything other than a compiler: that word, to
me, talks only about compilers.
Bootstrap, to me talks about the whole
Bootstrap, to me talks about the whole toolchain and all the library
that it uses.
I suppose it *can*, but that's not what term usually means.
Wouldn't you bootstrap an assembler written in assembly language?
Of course. But that's not relevant to this since we don't write the
I *suppose* you could include other parts of the toolchain in the bootstrap,
but I think the advantages of doing so are pretty small.
What about libraries used by GCC? From the user point of view it is a
bad bug that you cannot bootstrap a 64-bit compiler starting from a
32-bit one
From the user point of view it is a bad bug that you cannot bootstrap
a 64-bit compiler starting from a 32-bit one (because stage2 does not
find a 64-bit libiberty to use).
To me, bootstrap means that all three compilers are identical in
configuration, so I don't follow your example.
Richard Kenner wrote:
From the user point of view it is a bad bug that you cannot bootstrap
a 64-bit compiler starting from a 32-bit one (because stage2 does not
find a 64-bit libiberty to use).
To me, bootstrap means that all three compilers are identical in
configuration, so I don't
So the stage1 compiler is built as a 32-bit object, from the second
stage on they're built as 64-bit objects.
Very bad idea! I don't think we should support that.
The whole point of bootstrapping is that all of the stageN compilers should
behave identically and GCC simply doesn't do
BTW, I assume someone is working on fixing the fact that currently
there is no simple way to know at which stage the bootstrap is,
while it was obvious with the previous approach:
stage1/xgcc -Bstage1/
That'd be great.
Arno
Richard Kenner [EMAIL PROTECTED] wrote:
I would never use ../configure --disable-bootstrap make bootstrap,
but
I most certainly *would* use ../configure --disable-bootstrap; cd gcc;
make
bootstrap and would be *very* annoyed if it stoped working.
This *will* stop working, but you have good
So please, propose your usage case. Don't tell us which commands you expect
to be working, tell us of your workflow and why you think it's broken by the
new system. Probably it's just a misunderstanding, since there are no real
features that are being lost with the new system (while many bugs
On Mon, Jan 16, 2006 at 01:52:43PM +0100, Paolo Bonzini wrote:
I can see how a compiler bug, that manifests as a miscompilation of the
assembler, triggers a bootstrap failure if you also build the assembler
three times, each time using the previous compiler *and* assembler.
For the record,
This *will* stop working,
Then I'm confused: I thought the whole point of --disable-bootstrap is
to keep the old mechanism instead of getting the new one.
You will always have a bootstrap sequence and a non-bootstrap
sequence, but you'll need to reconfigure to switch between the
On Mon, Jan 16, 2006 at 09:03:26AM -0500, Richard Kenner wrote:
This *will* stop working,
Then I'm confused: I thought the whole point of --disable-bootstrap is
to keep the old mechanism instead of getting the new one.
The point of --disable-bootstrap is to disable bootstrapping. The
Of course in this case HOST_WIDE_INT is 64. I think we do guarantee
that, or cross compilation would be in big trouble.
No, it wouldn't be in big trouble: it didn't used to be 64 and it wasn't in
big trouble. The issue isn't if it *works*, but if the two compilers do the
identical
On 2006-01-16, at 14:37, Richard Kenner wrote:
So the stage1 compiler is built as a 32-bit object, from the
second
stage on they're built as 64-bit objects.
Very bad idea! I don't think we should support that.
Yeep. That's not a bootstrap. It's cross compilation.
The point is that 32-64 is a cross-compiler and it's only meaningful to talk
about bootstrapping a native compiler.
It's not 32-64. It's 64-64, but built with a 32-bit compiler.
Anyway, I find this discussion secondary now that we reached a point
from which I can help you.
You
The point of --disable-bootstrap is to disable bootstrapping.
Why would somebody ever want to *disable* it? If you don't want to
bootstrap, you just don't *do* it!
The most important of these is libgcc and the crt startup files, which
currently do live in the gcc directory, and
Then I'm confused: I thought the whole point of --disable-bootstrap is
to keep the old mechanism instead of getting the new one.
Not quite. You can do an old-style build and an old-style bootstrap from the
*toplevel* directory with --disable-bootstrap by issuing make and make
bootstrap
On Mon, Jan 16, 2006 at 09:24:29AM -0500, Richard Kenner wrote:
The point of --disable-bootstrap is to disable bootstrapping.
Why would somebody ever want to *disable* it? If you don't want to
bootstrap, you just don't *do* it!
Oh come on. This is semantics. --disable-bootstrap is
If you configure with --enable-languages=c,ada (which I guess is a good
option for you), a toplevel make does everything you need -- nothing
less, nothing more.
No, I want to configure with all the languages since I want to build them
all (and have to, in order to do a full make
On 2006-01-16, at 15:24, Richard Kenner wrote:
The point of --disable-bootstrap is to disable bootstrapping.
Why would somebody ever want to *disable* it? If you don't want to
bootstrap, you just don't *do* it!
The most important of these is libgcc and the crt startup
files, which
Why would somebody ever want to *disable* it? If you don't want to
bootstrap, you just don't *do* it!
Oh come on. This is semantics. --disable-bootstrap is the equivalent
of not doing it.
I don't follow. If I don't want to bootstrap, I won't say make bootstrap.
Why do I need
On Mon, Jan 16, 2006 at 09:48:14AM -0500, Richard Kenner wrote:
Why would somebody ever want to *disable* it? If you don't want to
bootstrap, you just don't *do* it!
Oh come on. This is semantics. --disable-bootstrap is the equivalent
of not doing it.
I don't follow.
Why is it so important to move them out? It would seem to me that the
bootstrap issue is a good reason *not* to!
There are very good reasons why libgcc and the crt
stuff should be separated from the compiler:
Those are not really parts of the compiler but libraries. They
Richard Kenner wrote:
If you configure with --enable-languages=c,ada (which I guess is a good
option for you), a toplevel make does everything you need -- nothing
less, nothing more.
No, I want to configure with all the languages since I want to build them
all (and have to, in order
Eric Botcazou wrote:
Then I'm confused: I thought the whole point of --disable-bootstrap is
to keep the old mechanism instead of getting the new one.
Not quite. You can do an old-style build and an old-style bootstrap from the
*toplevel* directory with --disable-bootstrap by issuing make
In the future, you will still be able to do an old-style build with
--disable-bootstrap (nobody ever wanted to prevent that). But you
will not be able to do an old-style bootstrap because the relevant
Makefile rules will be removed.
That's what I wanted my blurb to convey. :-)
--
Eric
Then it seems to me that you are just relying on a peculiarity of the
Ada build system, that is the fact that you can work entirely from
within the GCC directory.
That's by design, of course.
What you need to do then, is to run from the toplevel make
stage3-bubble; make -C
Richard Kenner wrote:
Then it seems to me that you are just relying on a peculiarity of the
Ada build system, that is the fact that you can work entirely from
within the GCC directory.
That's by design, of course.
Though it makes me wonder why people did not replicate the design
More like (cd gcc; make gnatlib_and_tools), i.e. the current
directory
is the same.
That matters?
$(PWD)
Well, right, those languages have front-ends written in C.
That's not the main difference, which is that for the other languages, you
can compile programs without an RTS since it's just used when the user
explicitly calls a library. But you cannot compile *any* Ada program (even
an empty
But you cannot compile *any* Ada program (even
an empty function) without an RTS in the path since it makes builtin
references to the RTS.
For what it's worth, that's the same for Java. But the compiler is not
written in Java so you can bootstrap it as part of GCC even if you
build libjava
And note that to me this is not really a bootstrap, because we're not
using jc1 in any way -- it's just built to stress test cc1! So your
stricter definition of a bootstrap is not really what GCC has been
doing for years. (Not that I don't understand your different
[EMAIL PROTECTED] (Richard Kenner) writes:
| Though it makes me wonder why people did not replicate the design for
| C++, Fortran (even old g77) and Java?
|
| I suspect it's because of the different role of the run-time library between
| Ada and those languages.
Could you elaborate?
This is the default setup you will run into on any ppc64-linux host. It's
definitely annoying that you have to workaround this in weird ways.
I don't follow. Why would you ever want to build the stage1 compiler as
a cross-compiler and then do a bootstrap? I don't consider starting
the
Paolo Bonzini [EMAIL PROTECTED] writes:
| But you cannot compile *any* Ada program (even
| an empty function) without an RTS in the path since it makes builtin
| references to the RTS.
|
| For what it's worth, that's the same for Java. But the compiler is
| not written in Java so you can
On 1/16/06, Richard Kenner [EMAIL PROTECTED] wrote:
This is the default setup you will run into on any ppc64-linux host. It's
definitely annoying that you have to workaround this in weird ways.
I don't follow. Why would you ever want to build the stage1 compiler as
a cross-compiler
So a naiive ./configure make will configure for host == target ==
powerpc64 but still (wrongly so in your opinion?) build stage1 as
32bit binaries (but defaulting to -m64 code generation now), and the
following stages will now become 64bit.
That's most *definitely* wrong because
On Monday 16 January 2006 16:46, Richard Kenner wrote:
So a naiive ./configure make will configure for host == target ==
powerpc64 but still (wrongly so in your opinion?) build stage1 as
32bit binaries (but defaulting to -m64 code generation now), and the
following stages
I don't see how this is any different to boostrapping gcc with any
other system compiler. It's fairly common for the system compiler to
use a different ABI to the new gcc. Why is 32/64-bit any different?
It isn't any different, which is the whole point. The point is that
what's being
Just to be clear, you're suggesting that if you have:
--build=powerpc-foo-bar --host=powerpc64-foo-bar --target=powerpc64-
foo-bar
The user be able to specify something so that the build systems knows
the build
machine can execute the host binaries, and a 4-stage bootstrap should
occur?
On Monday 16 January 2006 17:10, Richard Kenner wrote:
I don't see how this is any different to boostrapping gcc with any
other system compiler. It's fairly common for the system compiler to
use a different ABI to the new gcc. Why is 32/64-bit any different?
It isn't any
Just to be clear, you're suggesting that if you have:
--build=powerpc-foo-bar --host=powerpc64-foo-bar --target=powerpc64-foo-bar
The user be able to specify something so that the build systems knows
the build machine can execute the host binaries, and a 4-stage
bootstrap
I don't see why the requirement for a native compiler is anything
stronger than a binary that runs on this machine.
I native compiler is defined as one where host==target. Anything else
is something we call a cross-compiler.
Only if you assume a cross compiler and a true native
On Mon, Jan 16, 2006 at 12:43:13PM -0500, Richard Kenner wrote:
Only if you assume a cross compiler and a true native compiler
generate different code. I certainly hope that isn't the case.
Why not? It's a pretty strong statement to assume they generate *exactly* the
same code under
OK, so you want people to do
./configure --build=powerpc-foo-bar --host=powerpc-foo-bar --
target=powerpc64-foo-bar --prefix=$PWD/native64-compiler
make
make install
CC=$PWD/native64-compiler/bin/gcc /configure --build=powerpc64-foo-
bar --host=powerpc64-foo-bar --target=powerpc64-foo-bar
On 2006-01-16, at 18:38, Daniel Jacobowitz wrote:
As a heavy debugger of cross compilers I strongly disagree with this
sentiment. Host dependencies of any sort are a bug.
Amen to that. Independence from the host is paramount to
guarantee *reproducibility* of results over any on trivial time
On 1/16/06, Richard Kenner [EMAIL PROTECTED] wrote:
I don't see why the requirement for a native compiler is anything
stronger than a binary that runs on this machine.
I native compiler is defined as one where host==target. Anything else
is something we call a cross-compiler.
So any
As a heavy debugger of cross compilers I strongly disagree with this
sentiment. Host dependencies of any sort are a bug.
Amen to that. Independence from the host is paramount to guarantee
*reproducibility* of results over any on trivial time span. And
that's something
So any bi- or multi-arch configurations are then by definition both a
cross and a regular compiler at the same time?
Right, depending on the command line.
Or how do they fit in your scheme?
You bootstrap the native one and not the cross ones. ;-)
I never tried to bootstrap
I native compiler is defined as one where host==target. Anything
else is something we call a cross-compiler.
For the purposes of stage1, native only means runs on the build
machine, produces code that runs on the build machine. Since the
compiler used to build stage1 is *not* guaranteed to
On 1/16/06, Richard Kenner [EMAIL PROTECTED] wrote:
I never tried to bootstrap on x86_64 using --host=i686 --target=i686
to build a 32bit compiler building 32bit
Well, that's my point. It's not really a bootstrap. First you use the
cross-compiler to build a native compiler and
It is most definitely neccessary that GCC produce the same code
regardless of which compiler it is built with, assuming that the
compiler it is built with is not itself buggy.
Of course, but that's not what we're talking about.
A cross compiler and a native compiler targeting the
The question what is native here remains
I define native as meaning the target and host configurations are
the same. So a biarch compiler can be either native or cross depending on
whether or not the target is the same as that used to build itself.
On 2006-01-16, at 19:18, DJ Delorie wrote:
A cross compiler and a native compiler targeting the same CPU chip,
that's a different story.
No it isn't. The results should still be the same.
DJ Delorie [EMAIL PROTECTED] writes:
Two copies of gcc, both configured for the same target and built from
the same sources, should produce identical objects regardless of how
they are built or what they run on.
But note that we do not satisfy this today. Specifically if you build
gcc on two
No it isn't. The results should still be the same.
You aren't considering call ABI or PIC issues. Natives might have
different call-saved registers, or global fixed register (like the TLS
pointers), that affect optimization in different ways than an embedded
(no tls, different pic, different
On Mon, Jan 16, 2006 at 08:28:01PM +0100, Marcin Dalecki wrote:
On 2006-01-16, at 19:18, DJ Delorie wrote:
A cross compiler and a native compiler targeting the same CPU chip,
that's a different story.
No it isn't. The results should still be the same.
For a native compiler, the
But note that we do not satisfy this today.
So noted, and yes, I've been bitten by this bug and had to find a
machine with the right host configuration to reproduce customer bugs.
Hence I said should and not does :-P
I wrote:
For a native compiler, the bootstrap process guarantees (and even
partially tests) that, regardless of the original compiler, the object
code of generated compiler itself is byte-for-byte identical regardless of
which compiler we started with. Since the compiler itself is identical,
On 2006-01-16, at 20:35, DJ Delorie wrote:
No it isn't. The results should still be the same.
You aren't considering call ABI or PIC issues. Natives might have
different call-saved registers, or global fixed register (like the TLS
pointers), that affect optimization in different ways than
Oh, right. When I think cross compiler I assume for an embedded
target. Yes, two compilers with different $host but same $target
*should* (but currently don't) produce the same objects.
Two compilers with the same $host but different $target won't, even if
the two $targets are very similar.
make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java
Wow, that's awkward.
I understand, but I have a patch to make it easier.
Patches for the toplevel take a long time to review, and I cannot handle
posting too many patches and tracking them. Not even two patches. Currently I
So the previous system was easy? IMO it's just that it's been tested for
15 years. Personally it took me a lot of time to understand the working of
bubblestrap, stage*_copy, stage*_build, and so on
The previous make was easy. Now even make is too much intricate for
common mortals.
Except that host tools (fastjar mostly) are made with the *new* GCC
rather than the old one.
And the reason is what? I don't see even any theoretical merit in the
whole staging thing:
1. Bugs can theoretically cancel them self out.
2. The compiler isn't stressing himself more then the
Marcin Dalecki [EMAIL PROTECTED] writes:
| Testing the resulting compiler has already a name:
|
| make test
That does not test the compiler on building the runtime.
There are a number of times where people reported runtime buik
failures after front-end changes. So, I don't think your
68 matches
Mail list logo
