This is the mail archive of the
mailing list for the GCC project.
Re: [patch] rfa: fix problem with reassociating pointer additions
- From: Eric Christopher <echristo at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org, law at redhat dot com
- Date: Mon, 04 Oct 2004 20:13:36 -0700
- Subject: Re: [patch] rfa: fix problem with reassociating pointer additions
- References: <Pine.LNX.firstname.lastname@example.org>
On Mon, 2004-10-04 at 18:09, Roger Sayle wrote:
> On Mon, 4 Oct 2004, Eric Christopher wrote:
> > z = (int *) (a + (b + sizeof (c)));
> > We end up reassociating the constant addition into either
> > (a+(sizeof (c))) + b or
> > (a+b) + sizeof(c).
> > either could be a problem when dealing with pointer arithmetic near
> > the boundaries of addressable memory.
> Could you explain how this could be a problem near the boundaries of
> addressable memory? A failing testcase perhaps.
Sure. Say you're at the upper limit of available memory, 0x7ffffffc or
something on some random mips processor (rm7000 perhaps).
You're doing pointer arithmetic that puts you on the last page of memory
and you know this (you have carefully marked the last word of
addressable memory) and you access it like this:
pointer = location + value - sizeof(pointer);
Now, if this value ever goes above 0x7fffffff the addressing unit gives
a fault as determined from the processor manual, and you want to address
that last byte of memory, so you group the arithmetic like this:
pointer = location + (value - sizeof(pointer));
carefully avoiding overstepping the bounds of memory.
Now gcc comes up and rewrites it like this:
pointer = (location + value) - sizeof (pointer);
Undoing the precedence that you'd carefully set. The actual source code
to the failure comes from a customer and so that's why I had the cut
down testcase to show where the unwanted transformation was happening.
Make sense or should I try a different tack?
Eric Christopher <email@example.com>