This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] rfa: fix problem with reassociating pointer additions


On Tue, 2004-10-05 at 09:50, Daniel Jacobowitz wrote:
> On Tue, Oct 05, 2004 at 08:42:40AM -0700, Eric Christopher wrote:
> > 
> > > > I gave one in the thread...
> > > 
> > > No, you gave an example, not a test case :-)  A test case is something
> > > which can be compiled, and produces assembly which can at least be
> > > hand-inspected to understand the problem.  For instance, what is the
> > > exact assembly instruction that you're saying is a problem?
> > 
> > int *
> > foo (char *a, b)
> > {
> >   int c;
> >   int *z;
> > 
> >   z  = (int *) (a + (b - sizeof (c)));
> > 
> >   return z;
> > 
> > }
> > 
> > Where *a+b is something sufficiently large to go past 0x7fffffff and
> > will then reside in register, say, $3.
> > 
> > You'll get an instruction that looks like this:
> > 
> > lw $2,-4($3)
> > 
> > This instruction will trip an address exception on MIPS processors that
> > faithfully implement the standard - in kernel mode.
> 
> OK, now I understand.  This matches the example in the architecture
> manual.  The value in $3 will be 0xffffffff80000000, and the effective
> address in kernel mode of -4($3) will be 0xffffffff7ffffffc, which is
> invalid.
> 
> I think this is a thoroughly MIPS-specific problem
Nope.  This kind of address arithmetic reassociation can break
the PA and mn103 ports as well.



>  and, if you want to
> support it, you may need to hit a whole lot more places than you do
> now. 
Very possible.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]