> 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
On Sun, 15 Jan 2006, Daniel Berlin wrote:
> On Sun, 2006-01-15 at 18:35 -0500, Daniel Berlin wrote:
> > On Mon, 2006-01-16 at 00:24 +0100, Richard Guenther wrote:
> > > On Sun, 15 Jan 2006, Daniel Berlin wrote:
> > > >
> > > > Again, this is why i was not convinced that array aliasing by
> > > >
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 whol
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 *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
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'
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
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 h
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
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 two.
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
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
On Mon, 16 Jan 2006, Dominique Dhumieres wrote:
> > Can you send me this file (and all the files it requires)?
>
> You can find it on:
>
> http://www.lps.ens.fr/~dominiq/polyhedron/channel.f90
Ok, without the patch, compile-time is (f951 compiled with checking
enabled and -g):
[EMAIL PROTECTE
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 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 folk
> 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 c
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 n
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 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 orde
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
On Wednesday 21 December 2005 10:37, Zdenek Dvorak wrote:
> However, if we instead put a really minimal DECL node (we allocate only
> one per type, and consisting just of struct tree_common -- 16 bytes) as
> a SSA_NAME_VAR, things are much easier to get working.
>
I see that you are creating a tcc
> 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 gc
> I see that. I'm testing the following fix to address the fortran
> regressions. The observation is that the fortran FE uses structures
> to pass (lots of) arguments to I/O functions, and uses array descriptors
> for passing arrays, which are handled similarly. Now those structures
> are only _
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
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
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 func
> 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
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;
[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?
--
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
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
Hi Dorit,
What shall we do with gcc.dg/vect/vect-11.c? After I fixed PR
tree-optimization/25125, gcc.dg/vect/vect-11.c started failing on some
targets but not on x86_pc-linux-gnu. If we XFAIL it, we would get
XPASS on x86_pc-linux-gnu. I am pretty sure that adding -fwrapv will
fix the problem,
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
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
> What shall we do with gcc.dg/vect/vect-11.c? After I fixed PR
> tree-optimization/25125, gcc.dg/vect/vect-11.c started failing on some
> targets but not on x86_pc-linux-gnu.
It's gcc.dg/tree-ssa/gen-vect-11.c and it presumably fails everywhere.
But it is not run on x86-64 and ia64 so you don'
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
Hi Eric,
What shall we do with gcc.dg/vect/vect-11.c? After I fixed PR
tree-optimization/25125, gcc.dg/vect/vect-11.c started failing on some
targets but not on x86_pc-linux-gnu.
It's gcc.dg/tree-ssa/gen-vect-11.c and it presumably fails everywhere.
But it is not run on x86-64 and ia64 so
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
> I am pretty sure that adding -fwrapv will
> fix the problem, but that means we are changing the test case.
gen-vect-11.c is Paolo's test, so it's his call I guess
(he already agreed to add -fwrapv -
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00579.html)
dorit
Eric Botcazou <[EMAIL PROTECTED]
Dorit Nuzman wrote:
I am pretty sure that adding -fwrapv will
fix the problem, but that means we are changing the test case.
gen-vect-11.c is Paolo's test, so it's his call I guess
(he already agreed to add -fwrapv -
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00579.html)
Well, gen-ve
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
Paolo Bonzini <[EMAIL PROTECTED]> wrote on 16/01/2006 18:56:52:
> Dorit Nuzman wrote:
>
> >>I am pretty sure that adding -fwrapv will
> >>fix the problem, but that means we are changing the test case.
> >>
> >>
> >
> >gen-vect-11.c is Paolo's test, so it's his call I guess
> >(he already agreed to
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 diffe
On Fri, Jan 13, 2006 at 10:34:27AM +0800, Eric Fisher wrote:
> Hello,
> When I run the test suite for my port of gcc, there are some failures
> caused by the optimization flag such as -O2/-O3, and the messages are
> like,
>
> 930120-1.c: In function `f':
> 930120-1.c:138: internal compiler error:
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
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
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
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
Hello,
> On Wednesday 21 December 2005 10:37, Zdenek Dvorak wrote:
>
> > However, if we instead put a really minimal DECL node (we allocate only
> > one per type, and consisting just of struct tree_common -- 16 bytes) as
> > a SSA_NAME_VAR, things are much easier to get working.
> >
> I see that
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-comp
> 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
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* guaran
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
Philippe De Muyter wrote:
> For a mmu-less embedded target, I would like to generate code to run at
> a fixed location in read-only memory, but with the data segment located
> anywhere in memory. Therefore, the accesses to the data segement must go
> through an indirection table (GOT).
>
> I do n
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
> 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
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 identica
Due to
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00837.html
I got
cc1: warnings being treated as errors
/export/gnu/src/gcc/gcc/gcc/fold-const.c: In function ‘fold_minmax’:
/export/gnu/src/gcc/gcc/gcc/fold-const.c:7194: warning: ‘compl_code’
may be used uninitialized in this function make[5]:
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
On Mon, Jan 16, 2006 at 11:53:31AM -0800, H. J. Lu wrote:
> Due to
>
> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00837.html
>
> I got
>
> cc1: warnings being treated as errors
> /export/gnu/src/gcc/gcc/gcc/fold-const.c: In function ‘fold_minmax’:
> /export/gnu/src/gcc/gcc/gcc/fold-const.c:719
> cc1: warnings being treated as errors
> /export/gnu/src/gcc/gcc/gcc/fold-const.c: In function ‘fold_minmax’:
> /export/gnu/src/gcc/gcc/gcc/fold-const.c:7194: warning: ‘compl_code’
> may be used uninitialized in this function make[5]: *** [fold-const.o]
> Error 1
Interesting, there is a gcc_asser
On Jan 16, 2006, at 3:00 PM, H. J. Lu wrote:
This patch works for me.
But not the real problem. The real problem is the use of "gcc_assert
(FALSE);"
which just can be turned into gcc_unreachable as mentioned in my other
email.
-- Pinski
"H. J. Lu" <[EMAIL PROTECTED]> writes:
> 2006-01-16 H.J. Lu <[EMAIL PROTECTED]>
>
> * fold-const.c (fold_minmax): Always initialize compl_code.
>
> --- gcc/fold-const.c.foo 2006-01-16 11:33:31.0 -0800
> +++ gcc/fold-const.c 2006-01-16 11:56:13.0 -0800
> @@ -7191,14
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.
> 2006-01-16 H.J. Lu <[EMAIL PROTECTED]>
>
> * fold-const.c (fold_minmax): Always initialize compl_code.
That's not very elegant. Let's use gcc_unreachable () instead.
--
Eric Botcazou
Now that I've succeeded in building both a C and C++
cross-compiler for RDOS, I would like to build a native
version (although it probably won't run for a while yet).
I've tried to do it like this:
./configure --prefix=/usr/local --target=rdos --host=rdos
--enable-languages="c,c++" --with-newlib
On Wed, Dec 21, 2005 at 08:23:17PM +0200, Bernd Jendrissek wrote:
> I've been playing with my 16-bit ix86 port again,
I started coding one from scratch in about October or so. It has been
interesting.
[cut %bx as %bl and %bh in BASE_REGS]
> The simple solution was just to add %bh to BASE_REGS in
On Monday 16 January 2006 20:35, Leif Ekblad wrote:
> Now that I've succeeded in building both a C and C++
> cross-compiler for RDOS, I would like to build a native
> version (although it probably won't run for a while yet).
> I've tried to do it like this:
>
> ./configure --prefix=/usr/local --tar
> If you're trying to build a native hosted rdos compiler you need to have an
> rdos targeted (native hosted) cross compiler already in your path. This
> compiler will be used to build the target libraries.
Ugh. I used "native hosted" twice in the same sentence with two different
meanings. I mean
> with the patch applied it improves a little bit ;)
I get for the list I have sent:
snapshot 12/24 12/31 01/07 01/14 +patch
ac5.8s 6.0s 24.7s 23.0s+ 37.9s
aermod 223.9s227.3s485.8s467.6s+ 229.6s
air
On Mon, 16 Jan 2006, Dominique Dhumieres wrote:
> > with the patch applied it improves a little bit ;)
>
> I get for the list I have sent:
>
> snapshot 12/24 12/31 01/07 01/14 +patch
>
> ac5.8s 6.0s 24.7s 23.0s+ 37.9s
Hm, so that
On Wed, Dec 21, 2005 at 03:07:21PM -0500, DJ Delorie wrote:
>
> > It was because I had decided to expose the registers as %al, %ah,
> > ... %bl, %bh, ... instead of the customary %[e]ax and friends.
>
> I originally did this for the m32c port (which has hi/low pairs like
> the i386) but discover
> > ac5.8s 6.0s 24.7s 23.0s+ 37.9s
>
> Hm, so that regresses even more. Weird. I'd like to have it to
> investigate.
Sorry this was a typo, the first two lines should be:
ac5.8s 6.0s 24.7s 23.0s+4.0s
aermod 223.9s227.3s
I'm trying to bootstrap various GCC branches with --disable-nls on a
system where the admin installed GNU libiconv in the default directory
for GNU software, namely /usr/local. I'm having problems getting the
configury process to stop trying to use the GNU version and instead
work with the system
On Mon, Jan 16, 2006 at 07:22:28PM -0500, Kaveh R. Ghazi wrote:
> I'm trying to bootstrap various GCC branches with --disable-nls on a
> system where the admin installed GNU libiconv in the default directory
> for GNU software, namely /usr/local.
I had a similar issue a while back:
http://gcc.gnu
> > When I add --without-libiconv-prefix, it seems to avoid finding
> > libiconv.so during configure in stage1, but it still uses the wrong
> > iconv.h as of stage2. And with mainline, since configure is run
> > every stage it gets worse.
> > Any ideas?
>
> Make an explicit with-libiconv-p
> Patch is OK if bootstrapped, etc.
Passed bootstrap/check/regression. Committed. Thanks!
2006-01-16 DJ Delorie <[EMAIL PROTECTED]>
* reload.c (reg_overlap_mentioned_for_reload_p): Handle subregs of
mems.
Index: reload.c
=
What coding system are we following in ChangeLogs? We're starting to
collect various 8-bit characters in people's names (which is a good
sign, I suppose) but Emacs complained that it couldn't figure out the
encoding this last time around. A quick egrep shows a mix of
obviously iso-latin-1 charac
On the Ada side for 4.1:
- x86-linux is fine, 0 ACATS FAIL on i686 and i486
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00632.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00148.html
- powerpc-darwin doesn't bootstrap => PR 22533, regression from 4.0),
Richard, Eric, Andrew, do you h
I'm getting a parallel build failure on mainline like so:
> make[3]: *** No rule to make target `gt-c-pragma.h', needed by `c-pragma.o'.
> Stop.
We have c-pragma.o depend on gt-c-pragma.h, but there's no rule to
build gt-c-pragma.h. I assume gt-c-pragma.h needs to depend on
s-gtype, but I th
1 - 100 of 103 matches
Mail list logo
