Re: GCC 4.4.0 Status Report (2008-09-09)

DJ Delorie wrote: Presumably you're discussing these with Vlad? We did exchange some emails about it, yes. Feel free to post stuff to the main list as well -- we lose nothing by expanding the public understanding of the issues you're trying to tackle and who knows, someone might have

Re: GCC 4.4.0 Status Report (2008-09-09)

> Presumably you're discussing these with Vlad? We did exchange some emails about it, yes.

Re: GCC 4.4.0 Status Report (2008-09-09)

DJ Delorie wrote: The following ports are unconverted and I don't recall seeing people saying they were working on IRA ports, although I may have missed such statements: m32c I am working on m32c but so far have not had good results. All class combinations I've tried so far result in bui

Re: GCC 4.4.0 Status Report (2008-09-09)

> The following ports are unconverted and I don't recall seeing people > saying they were working on IRA ports, although I may have missed such > statements: > > m32c I am working on m32c but so far have not had good results. All class combinations I've tried so far result in build failures in

GCC 4.4.0 Status Report (2008-09-09)

Status == Trunk in in Stage 3, so only bug fixes, documentation changes and new ports are generally allowed, subject to the discretion of individual maintainers. I discussed the nature of that discretion and how some maintainers need to be more conservative than others in

Re: building a biarch compiler on sparc-linux-gnu --with-cpu=v9

> v9 means 64 bits. You probably want to use v8plus instead, which > corresponds to 32-bit instructions on an UltraSparc CPU. Not necessarily. If you pass -mcpu=v9 to the 32-bit SPARC compiler, it still emits code which is compliant with the 32-bit ABI. On Solaris the 32-bit compiler defaults t

Re: building a biarch compiler on sparc-linux-gnu --with-cpu=v9

Matthias Klose a écrit : > I'm currently building trunk on sparc-linux-gnu (32bit) configured with > > --enable-targets=all --with-cpu=v8 > > trying to change that to > > --enable-targets=all --with-cpu=v9 > > two 64bit libgcc's are built. it looks like v9 and 64bit are tightly > coupled in

building a biarch compiler on sparc-linux-gnu --with-cpu=v9

I'm currently building trunk on sparc-linux-gnu (32bit) configured with --enable-targets=all --with-cpu=v8 trying to change that to --enable-targets=all --with-cpu=v9 two 64bit libgcc's are built. it looks like v9 and 64bit are tightly coupled in the configury. how can this be setup to buil

Re: IRA performance regressions on PPC

On Tue, Sep 9, 2008 at 11:13 AM, Luis Machado <[EMAIL PROTECTED]> wrote: > On Mon, 2008-09-08 at 09:47 -0400, Vladimir Makarov wrote: >> Jeff Law wrote: >> > H.J. Lu wrote: >> >> My understanding is PowerPC is quite sensitive to choice of register >> >> as shown in PR 28690. IRA merge may make fixe

Re: IRA performance regressions on PPC

On Mon, 2008-09-08 at 09:47 -0400, Vladimir Makarov wrote: > Jeff Law wrote: > > H.J. Lu wrote: > >> My understanding is PowerPC is quite sensitive to choice of register > >> as shown in PR 28690. IRA merge may make fixes for PR 28690 > >> ineffective. There are a few small testcases in PR 28690. Y

State of the art of optimisations

Hi all, With the range of optimisation passes that are currently part of GCC (and in modern optimising compilers in general), what would you regard as the greatest developments in compiler optimisation technology over the past ten years? Do you think that is it the development of intermediate for

Re: Passing LDFLAGS to stage2 and stage3 gcc

Rainer Emrich wrote: > [EMAIL PROTECTED] schrieb: >> Rainer Emrich <[EMAIL PROTECTED]> wrote: >>> So I wan't to pass LDFLAGS="-Wl, -rpath, /somedir" to stage3 to link gcc, >>> cpp, >>> etc. with the rpath information. >> I do this by editing LDFLAGS_FOR_TARGET in the top-level Makefile.in, >> and

Re: Passing LDFLAGS to stage2 and stage3 gcc

[EMAIL PROTECTED] schrieb: > Rainer Emrich <[EMAIL PROTECTED]> wrote: >> So I wan't to pass LDFLAGS="-Wl, -rpath, /somedir" to stage3 to link gcc, >> cpp, >> etc. with the rpath information. > > I do this by editing LDFLAGS_FOR_TARGET in the top-level Makefile.in, > and also passing LDFLAGS, BOOT

Re: Passing LDFLAGS to stage2 and stage3 gcc

Rainer Emrich <[EMAIL PROTECTED]> wrote: > So I wan't to pass LDFLAGS="-Wl, -rpath, /somedir" to stage3 to link gcc, cpp, > etc. with the rpath information. I do this by editing LDFLAGS_FOR_TARGET in the top-level Makefile.in, and also passing LDFLAGS, BOOT_LDFLAGS, and HOST_LDFLAGS assignments as

Passing LDFLAGS to stage2 and stage3 gcc

What I'm trying to do is the following: I have a couple of cross compilers in a non default place. To avoid setting LD_LIBRARY_PATH to find libgmp and libmpfr I used static ones until now. Now ppl and cloog are coming in to play for trunk. Using static libraries for all the four liberaries doesn'