pr45605.C devirtualize call failure in ia64-hp-hpux?

2012-04-30 Thread Mailaripillai, Kannan Jeganathan
Hi, This is related to pr45605.C test. Reduced testcase struct B { virtual void Run(){}; }; struct D : public B { virtual void Run() { }; }; int main() { D d; static_cast(d).Run(); } With x86_64 linux the call to Run through object d is devirtualized. Whereas it looks like in ia6

Re: pr45605.C devirtualize call failure in ia64-hp-hpux?

2012-04-30 Thread Eric Botcazou
> With x86_64 linux the call to Run through object d is devirtualized. > Whereas it looks like in ia64 hp-ux it is not devirtualized. > > -fdump-tree-fre1 output for both: > > x86_64 linux: > > MEM[(struct B *)&d]._vptr.B = &MEM[(void *)&_ZTV1B + 16B]; > d.D.2197._vptr.B = &MEM[(void *)&_Z

Re: making sizeof(void*) different from sizeof(void(*)())

2012-04-30 Thread Paulo J. Matos
Peter, We have a working backend for an Harvard Architecture chip where function pointer and data pointers have necessarily different sizes. We couldn't do this without changing GCC itself in strategic places and adding some extra support in our backend. We haven't used address spaces or any

Re: making sizeof(void*) different from sizeof(void(*)())

2012-04-30 Thread Robert Dewar
On 4/30/2012 4:16 AM, Paulo J. Matos wrote: Peter, We have a working backend for an Harvard Architecture chip where function pointer and data pointers have necessarily different sizes. We couldn't do this without changing GCC itself in strategic places and adding some extra support in our backen

Re: making sizeof(void*) different from sizeof(void(*)())

2012-04-30 Thread Peter Bigot
On Mon, Apr 30, 2012 at 4:50 AM, Robert Dewar wrote: > On 4/30/2012 4:16 AM, Paulo J. Matos wrote: >> >> Peter, >> >> We have a working backend for an Harvard Architecture chip where >> function pointer and data pointers have necessarily different sizes. We >> couldn't do this without changing GCC

Re: Fwd: Using movw/movt rather than minipools in ARM gcc

2012-04-30 Thread Richard Earnshaw
On 27/04/12 21:24, David Sehr wrote: > Hello All, > > We are using gcc trunk as of 4/27/12, and are attempting to add > support to the ARM gcc compiler for Native Client. > We are trying to get gcc -march=armv7-a to use movw/movt consistently > instead of minipools. The motivation is for > a new t

No documentation of -fsched-pressure-algorithm

2012-04-30 Thread Nick Clifton
Hi Richard, I have just noticed that the new -fsched-pressure-algorithm= gcc command line option is not documented in gcc/doc/invoke.texi. Was this an oversight ? Cheers Nick

Re: No documentation of -fsched-pressure-algorithm

2012-04-30 Thread Richard Sandiford
Nick Clifton writes: > I have just noticed that the new -fsched-pressure-algorithm= gcc > command line option is not documented in gcc/doc/invoke.texi. Was > this an oversight ? No, it was deliberate. It's not supposed to be a user-level option. Richard

Re: Fwd: Using movw/movt rather than minipools in ARM gcc

2012-04-30 Thread Roland McGrath
On Mon, Apr 30, 2012 at 9:02 AM, Richard Earnshaw wrote: > It very much depends on your processor. I suppose we are probably concerned primarily with recentish OMAP and Tegra2 sorts of processors, but we are looking for generic good performance solutions for ARMv7-A class processors. > MOVW/MOVT

Re: go in 4.7.0 seems to fail quite badly

2012-04-30 Thread Ian Lance Taylor
Dennis Clarke writes: > Has anyone seen better results from the testsuite for GO ? Yes. I test Go more than daily on x86_64-unknown-linux-gnu, and I see no failures at all. > FAIL: go.go-torture/execute/go-1.go execution, -O0 To see why these tests are failing, look in gcc/testsuite/go/go.l

Re: [RFC] Converting end of loop computations to MIN_EXPRs.

2012-04-30 Thread Ramana Radhakrishnan
Sorry about the delayed response, I've been away for some time. > > I don't exactly understand why the general transform is not advisable. > We already synthesize min/max operations. > > Can you elaborate on why you think that better code might be generated > when not doing this transform? The