This is the mail archive of the 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, 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

I think this is a thoroughly MIPS-specific problem and, if you want to
support it, you may need to hit a whole lot more places than you do
now.  I don't see that there's a sensible solution in GCC - like Thiemo
said, this is why sensible MIPS OS's avoid the entire problem by
blacklisting that 32K.

Daniel Jacobowitz

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