On Wed, 7 May 2008, Peter Bergner wrote:
> Note that the rtlanal.c:ÿÿcommutative_operand_precedence() hunk was reverted
> because it caused some problems on CRIS
For the record, that's a simplification. It breaking CRIS
wasn't the main reason for the revert. I applied a fix, but
raised a general
Peter Bergner wrote:
On Thu, 2008-05-08 at 11:38 -0700, Steve Ellcey wrote:
The psuedo for %r8 does have REG_POINTER set and the psuedo for %r19
does not. I first see REG_POINTER set for ivtmp___1536 (the psuedo for
%r8) in flow.c.138r.loop2_invariant. This seems interesting because
Peter's pa
On Thu, 2008-05-08 at 11:38 -0700, Steve Ellcey wrote:
> The psuedo for %r8 does have REG_POINTER set and the psuedo for %r19
> does not. I first see REG_POINTER set for ivtmp___1536 (the psuedo for
> %r8) in flow.c.138r.loop2_invariant. This seems interesting because
> Peter's patch, that fixes
On Thu, May 8, 2008 at 11:48 AM, Jeff Law <[EMAIL PROTECTED]> wrote:
> Hmmm, fails for 4.3... Hmmm, does 4.3 have POINTER_PLUS_EXPR?
> (search tree.def for POINTER_PLUS_EXPR).
Yes it made it in 4.3 :). Which is why the other patch went in.
Thanks,
Andrew Pinski
Steve Ellcey wrote:
The psuedo for %r8 does have REG_POINTER set and the psuedo for %r19
does not. I first see REG_POINTER set for ivtmp___1536 (the psuedo for
%r8) in flow.c.138r.loop2_invariant. This seems interesting because
Peter's patch, that fixes this problem without undoing Andrews pat
> If I am reading things right, the use of r8 and r19 in the ldw
> instruction are switched around.
Yes. If you do an rtl dump, you should be able to see where the
REG_POINTER flag gets set and if the operand order gets switched.
Sometimes the REG_POINTER flag gets removed by reload, etc. So,
th
Jeff Law wrote:
> And just to be certain, we've used a recent GCC trunk to compile an old
> rev of gcc (2.7 era?), which is then segfaulting when it's trying to
> compile code, right?
Correct, I am using GCC 4.3.0 to compile the old (2.7) GCC and when I
run that old GCC it segfaults. If I star
Steve Ellcey wrote:
If it aborts, as in calling abort, rather than segfaulting, then it's
not a flipped base/index in a memory reference -- those almost always
segfault. This is the case that most worries me about Andrew's patch.
Sorry I wasn't clearer, it is a segfault. Running under gdb:
> If it aborts, as in calling abort, rather than segfaulting, then it's
> not a flipped base/index in a memory reference -- those almost always
> segfault. This is the case that most worries me about Andrew's patch.
Sorry I wasn't clearer, it is a segfault. Running under gdb:
Program received
Steve Ellcey wrote:
Steve Ellcey wrote:
I am investigating a bad code generation bug on the 64 bit HPPA platform
with GCC 4.3.0 and would like some help and/or ideas on how to analyze
and fix it. The failing test is the SPEC 2000 GCC benchmark (version
2.7.2.2) and I have been unable to create
On Wed, 2008-05-07 at 11:03 -0700, Steve Ellcey wrote:
> > Can you please also add the replacement hunk from:
> >
> > o;?http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00693.html
> >
> > If the first part gets backported, I'd like the second hunk to
> > go along with it if possible. Thanks.
> >
> Can you please also add the replacement hunk from:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00693.html
>
> If the first part gets backported, I'd like the second hunk to
> go along with it if possible. Thanks.
>
> Peter
I was wondering about that patch since it seems to be relat
On Wed, 2008-05-07 at 10:10 -0700, Steve Ellcey wrote:
> Yes, it looks like it is. I added -fno-strict-aliasing and the perl
> benchmarks passed when compiled with ToT GCC. That makes me feel better
> about the idea of putting Peter's patch (with the revert) on the 4.3
> branch as a way to fix th
> Hi Steve,
>
> Is your perl test problem the same as
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
>
>
> H.J.
Yes, it looks like it is. I added -fno-strict-aliasing and the perl
benchmarks passed when compiled with ToT GCC. That makes me feel better
about the idea of putting Peter's
On Wed, May 7, 2008 at 9:21 AM, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> > From: Peter Bergner <[EMAIL PROTECTED]>
>
>
> >
> > On Wed, 2008-05-07 at 07:45 -0700, Steve Ellcey wrote:
> > > I have found that this problem does not occur on the ToT sources and
> > > that the problem went away with
> From: Peter Bergner <[EMAIL PROTECTED]>
>
> On Wed, 2008-05-07 at 07:45 -0700, Steve Ellcey wrote:
> > I have found that this problem does not occur on the ToT sources and
> > that the problem went away with this patch:
> >
> > 2008-04-07 Peter Bergner <[EMAIL PROTECTED]>
> >
> >PR
On Wed, 2008-05-07 at 07:45 -0700, Steve Ellcey wrote:
> I have found that this problem does not occur on the ToT sources and
> that the problem went away with this patch:
>
> 2008-04-07 Peter Bergner <[EMAIL PROTECTED]>
>
>PR middle-end/PR28690
>* rtlanal.c: Update copyright
> Steve Ellcey wrote:
> > I am investigating a bad code generation bug on the 64 bit HPPA platform
> > with GCC 4.3.0 and would like some help and/or ideas on how to analyze
> > and fix it. The failing test is the SPEC 2000 GCC benchmark (version
> > 2.7.2.2) and I have been unable to create a sma
Steve Ellcey wrote:
I am investigating a bad code generation bug on the 64 bit HPPA platform
with GCC 4.3.0 and would like some help and/or ideas on how to analyze
and fix it. The failing test is the SPEC 2000 GCC benchmark (version
2.7.2.2) and I have been unable to create a smaller test case s
19 matches
Mail list logo
