On Mon, 16 Jan 2006, DJ Delorie wrote:
> 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.
For the record, this unfortunately isn't so, at least wasn't
weeks ago, compar
On Jan 18, 2006, at 5:26 AM, Paolo Bonzini wrote:
MRS and Eric Botcazou objected strongly against not being able to
build a 1-stage GCC with --disable-bootstrap. And that's never
going to happen.
I tend to like long term stability in who things are done, but I'm
not stuck in the mud, the
On Wed, Jan 18, 2006 at 08:44:37AM -0600, Gabriel Dos Reis wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> | On Wed, Jan 18, 2006 at 08:36:13AM -0500, Richard Kenner wrote:
> | > MRS and Eric Botcazou objected strongly against not being able to
> | > build a 1-stage GCC with --d
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 direc
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
| On Wed, Jan 18, 2006 at 08:36:13AM -0500, Richard Kenner wrote:
| > MRS and Eric Botcazou objected strongly against not being able to
| > build a 1-stage GCC with --disable-bootstrap. And that's never going
| > to happen.
| >
| > One wo
On Wed, Jan 18, 2006 at 08:36:13AM -0500, Richard Kenner wrote:
> MRS and Eric Botcazou objected strongly against not being able to
> build a 1-stage GCC with --disable-bootstrap. And that's never going
> to happen.
>
> One would hope that wouldn't, but what I heard was an objection
>
MRS and Eric Botcazou objected strongly against not being able to
build a 1-stage GCC with --disable-bootstrap. And that's never going
to happen.
One would hope that wouldn't, but what I heard was an objection
against removing what's there now, namely the capability to bootstrap
GCC a
Richard Kenner wrote:
I've seen many people saying not wanting something to go away, but
that something is not proposed by Paolo to disappear.
Can you say *exactly* what those two different things are because I'm confused?
Thanks.
MRS and Eric Botcazou objected strongly against not bei
I've seen many people saying not wanting something to go away, but
that something is not proposed by Paolo to disappear.
Can you say *exactly* what those two different things are because I'm confused?
Thanks.
[EMAIL PROTECTED] (Richard Kenner) writes:
| As I said multiple times, *of course* bootstrapping will *never* be
| mandatory. On the other hand, GCC-only bootstrapping
| (i.e. configuring with disabled bootstrap, and then typing "make
| bootstrap") will be deleted.
|
| You've now
Who? Most people I've read the messages of, believed that
disable-bootstrap would have been deleted tout court, without providing
a way of building a non-self-built GCC.
There are too many negations in that sentence for me to understand exactly
what you're saying, but what I'm sayin
Richard Kenner wrote:
As I said multiple times, *of course* bootstrapping will *never* be
mandatory. On the other hand, GCC-only bootstrapping
(i.e. configuring with disabled bootstrap, and then typing "make
bootstrap") will be deleted.
You've now heard *a lot* of people say that t
As I said multiple times, *of course* bootstrapping will *never* be
mandatory. On the other hand, GCC-only bootstrapping
(i.e. configuring with disabled bootstrap, and then typing "make
bootstrap") will be deleted.
You've now heard *a lot* of people say that they don't want this d
Mike Stump wrote:
On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote:
Steven Bosscher wrote:
... you can use --disable-bootstrap and do a regular make, or is there
some reason why you can't do that?
I thought the point was that that option is temporary and will go away.
Over my d
On Jan 17, 2006, at 10:30 PM, Mike Stump wrote:
On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote:
Steven Bosscher wrote:
... you can use --disable-bootstrap and do a regular make, or is
there
some reason why you can't do that?
I thought the point was that that option is temporary an
On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote:
Steven Bosscher wrote:
... you can use --disable-bootstrap and do a regular make, or is
there
some reason why you can't do that?
I thought the point was that that option is temporary and will go
away.
Over my dead body. We will al
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.
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
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 identica
> 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
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
> 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 A
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
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.
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.
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
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
> 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* guaran
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
> 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 hig
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-comp
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
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
m
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
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 na
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 shou
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 diffe
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?
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
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 stage
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 becaus
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-com
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 ca
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
On 1/16/06, Richard Kenner <[EMAIL PROTECTED]> 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.
This is the default setup you will run into on any ppc64-linux h
[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?
--
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
definition;
> 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 libja
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 func
More like "(cd gcc; make gnatlib_and_tools)", i.e. the current
directory
is the same.
That matters?
$(PWD)
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.
More like "(cd gcc; make gnatlib_and_tools)", i.e. the current directory
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 for
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 gc
> 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
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" a
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 orde
> 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
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 f
> 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 n
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
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 c
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
> 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"
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 folk
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
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.
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 thing
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. Th
BTW, did you capture the fact that BOOT_ADAFLAGS are no longer
passed with the new configure; make bootstrap ? FWIW, I can't really do
more testing or give more feedback on the new approach until this is
fixed.
I just verified that it works with --disable-bootstrap; make bootstrap.
As for bootstr
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 two.
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,
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 an
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 h
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
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 tha
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'
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.
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 (beca
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
compi
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 whol
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
> 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 p
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 statem
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 targ
> > 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
> 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.
>
> 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
Jason Merrill <[EMAIL PROTECTED]> writes:
> Remind me why it's a good idea to force me to mess with bootstrapping
> at all, when all I want is to build a copy of the compiler that I can
> use for debugging problems? There has to be an easier way to do that.
> My laptop builds stage1 reasonably fa
Steven Bosscher wrote:
> ... you can use --disable-bootstrap and do a regular make, or is there
> some reason why you can't do that?
I wasn't aware of the option. Guess I'll do that, then.
I thought the point was that that option is temporary and will go away.
Did I misundersta
Steven Bosscher wrote:
... you can use --disable-bootstrap and do a regular make, or is there
some reason why you can't do that?
I wasn't aware of the option. Guess I'll do that, then.
Jason
On 2006-01-13, at 23:59, Richard Kenner wrote:
Remind me why it's a good idea to force me to mess with
bootstrapping
at all, when all I want is to build a copy of the compiler that
I can
use for debugging problems?
Well install.texi explains in full lenght the wonders of the b
On Fri, Jan 13, 2006 at 05:15:40PM -0500, Jason Merrill wrote:
> Paolo Bonzini wrote:
> >
> >>So, how would I now get a cc1plus/f951/jc1/cc1 binary compiled by the
> >>stage0 (host) compiler?
>
> >make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java
>
> Wow, that's awkward.
>
> >I think that
FWIW I personally think this toplevel bootstrap thing is a step
backward, now
typing "make" triggers such a complex machinery that nobody seems
to able to
understand what it does.
Please forgive my ginorace but I didn't consider the autoconf/
automake/gnumake mechanism
to be entierly trasp
> Remind me why it's a good idea to force me to mess with bootstrapping at
> all, when all I want is to build a copy of the compiler that I can use
> for debugging problems? There has to be an easier way to do that. My
> laptop builds stage1 reasonably fast, but a bootstrap takes several hours.
Remind me why it's a good idea to force me to mess with bootstrapping
at all, when all I want is to build a copy of the compiler that I can
use for debugging problems? There has to be an easier way to do that.
My laptop builds stage1 reasonably fast, but a bootstrap takes several
Paolo Bonzini wrote:
So, how would I now get a cc1plus/f951/jc1/cc1 binary compiled by the
stage0 (host) compiler?
make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java
Wow, that's awkward.
I think that after I fix PR25670, as a side effect, you will also be
able to use the more intuiti
On Thursday 05 January 2006 03:40, Paolo Bonzini wrote:
> make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java
>
>
OK, thanks. That worked for a recently configured compiler. Now, suppose
I had:
$ ../trunk/configure
$ make bootstrap check
I now see a few failures that I want to check, so I
On Thursday 05 January 2006 03:40, Paolo Bonzini wrote:
> make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java
>
Sorry, but this didn't help. This left me with only the cc1 binary in
bld/gcc:
$ cd
$ make clean
$ make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran
$ ls gcc/f951 gcc/cc1plus gcc/
make all-stage2 STAGE1_LANGUAGES=c,fortran
So, how would I now get a cc1plus/f951/jc1/cc1 binary compiled by the
stage0 (host) compiler?
That would give me the 4 '-g -O0' binaries compiled with the system
compiler. I've tried following these notes, but it always gives me
binaries built
On Monday 02 January 2006 03:33, Paolo Bonzini wrote:
> make all-stage2 STAGE1_LANGUAGES=c,fortran
>
So, how would I now get a cc1plus/f951/jc1/cc1 binary compiled by the
stage0 (host) compiler?
Before, I used to do (inside /gcc):
$ make restage1 f951 cc1plus jc1
That would give me the 4 '
100 matches
Mail list logo
