Re: Is this the expected behavior?

Hi Mohamed, Why not ? Callee save registers are after all registers and the split is in the ABI's head (so to speak). So GCC is well within its right to use callee save registers. In fact if you were in a leaf function that did not make any function calls the first preference would be to allocat

Is this the expected behavior?

Hello all, I am not sure if this the right mailing list. I am involved in the porting of gcc 4.1.2 for a 16 bit target. In some cases i noticed that callee save registers were getting allocated in the body even though there isn't any function call. I believe that callee save registers will be all

Re: [tuples] Bootstrap failure building libjava on ppc64

On Mon, Jul 14, 2008 at 5:22 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > We are failing to build libjava on PPC64 because of this: > > /home/dnovillo/perf/sbox/tuples/local.ppc64/bld/./gcc/xgcc -shared > -libgcc -B/home/dnovillo/perf/sbox/tuples/local.ppc64/bld/./gcc > -nostdinc++ -L/home/d > no

Re: New branch for STL Advisor

On Mon, Jul 14, 2008 at 7:20 PM, Benjamin Kosnik <[EMAIL PROTECTED]> wrote: > In particular, design. The using bits seem pretty straightforward. It > would be nice if you could provide some detail in terms of scope (what > are the algorithms or data structures you intend to instrument), > and how t

Re: New branch for STL Advisor

Hi Silvius Rus and Lixia Liu! Thanks for posting this, asking for advice, and being willing to help improve libstdc++! > Goal: Give performance improvement advice based on analysis of > dynamic STL usage. Your project sounds intriguing, and something that could potentially be useful for GNU C++

Re: [m32c] newlib build failure in reload

> If reload is generally flaky like this for m32c, perhaps a target macro to > say not to reload addresses in the particular case my patch affects would > be a sensible approach, if things worked better without reloading them > even though as far as reload knows they need reloading. I wouldn't

Re: [m32c] newlib build failure in reload

On Mon, 14 Jul 2008, DJ Delorie wrote: > I did some work a while back to try to rearrange the reloads so that > registers could be reused, but IMHO the right solution is for gcc to > realize that it needs to break the insn up and reload the parts > separately, perhaps a "relaxing reloader" that ca

Re: [m32c] newlib build failure in reload

> You should file a PR in any case. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827 > Does m32c handle some addresses specially in any way at all similar to the > special SH handling discussed in PR 36780 and > ? Because some > sort

Re: [tuples] Jakub is now branch maintainer

On Mon, Jul 14, 2008 at 02:28:51PM -0700, Diego Novillo wrote: > Jakub, > > You've been doing great work on the branch, so Aldy and I think that > you don't really need patch approval for branch patches anymore. So, > from now on, feel free to commit your patches without waiting for an > explicit

[tuples] Jakub is now branch maintainer

Jakub, You've been doing great work on the branch, so Aldy and I think that you don't really need patch approval for branch patches anymore. So, from now on, feel free to commit your patches without waiting for an explicit approval. If there is something that needs to be addressed, we can do it

Re: [m32c] newlib build failure in reload

On Mon, 14 Jul 2008, DJ Delorie wrote: > Been getting this for a while, finally had time and resources to track it > down. > It was introduced by 137639: > > 2008-07-08 Joseph Myers <[EMAIL PROTECTED]> > > * reload.c (find_reloads_subreg_address): Do not require validity > of addr

[tuples] Bootstrap failure building libjava on ppc64

We are failing to build libjava on PPC64 because of this: /home/dnovillo/perf/sbox/tuples/local.ppc64/bld/./gcc/xgcc -shared -libgcc -B/home/dnovillo/perf/sbox/tuples/local.ppc64/bld/./gcc -nostdinc++ -L/home/d novillo/perf/sbox/tuples/local.ppc64/bld/powerpc64-unknown-linux-gnu/libstdc++-v3/src

[m32c] newlib build failure in reload

Been getting this for a while, finally had time and resources to track it down. It was introduced by 137639: 2008-07-08 Joseph Myers <[EMAIL PROTECTED]> * reload.c (find_reloads_subreg_address): Do not require validity of address in original mode before reloading address. It w

Re: GCC 4.3.2 Status Report (2008-07-14)

On Mon, 14 Jul 2008, NightStrike wrote: > On 7/14/08, Richard Guenther <[EMAIL PROTECTED]> wrote: > > > > Status > > == > > > > The GCC 4.3 branch is open for commits under normal release branch > > rules. The 4.3.2 release is expected around 2008-08-06. > > > > Quality Data > >

Re: GCC 4.3.2 Status Report (2008-07-14)

On 7/14/08, Richard Guenther <[EMAIL PROTECTED]> wrote: > > Status > == > > The GCC 4.3 branch is open for commits under normal release branch > rules. The 4.3.2 release is expected around 2008-08-06. > > Quality Data > > > Priority # Change from Last Report > ---

Re: Optimizing for size

This could be related to PR31849. If so, this is well-known before the 4.3.0 release, and altought IIRC it affects other architetures as well (powerpc and m68k at least), apparently no one proposed a solution yet. Please see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849 Thanks, Alexandre

Re: Optimising for size

Joe Buck wrote: On Mon, Jul 14, 2008 at 10:04:08AM +1000, [EMAIL PROTECTED] wrote: I have a piece of C code. The code, compiled to an ARM THUMB target using gcc 4.0.2, with -Os results in 230 instructions. The exact same code, using the exact same switches compiles to 437 instructions with gc

Another recent libstdc++ regression

Hi, first, many thanks to Daniel for working hard on the other recent regressions... Unfortunately, however, today there is a new one (at least on x86_64-linux and i686-linux): FAIL: 22_locale/num_put/put/wchar_t/20914.cc execution test Many thanks for looking into it and, well... to whom is

GCC 4.3.2 Status Report (2008-07-14)

Status == The GCC 4.3 branch is open for commits under normal release branch rules. The 4.3.2 release is expected around 2008-08-06. Quality Data Priority # Change from Last Report --- --- P18 +- 0 P2