Re: loop-2{f,g} failures

["David S. Miller" <davem at dm dot cobaltmicro dot com>]

   Date: Wed, 26 Aug 1998 20:53:48 -0600
   From: Jeffrey A Law <law@cygnus.com>

     In message <19980826102017.C29439@dgii.com>you write:
     > Can anyone briefly comment on these failures?  Are these known to be
     > fragile? In all the mmap voodoo in those test cases, have we perhaps
     > introduced a dependence on library/mmap/vm behaviour?

   They're designed to tickle very obscure bugs in the loop optimizer.
   It's unlikely they're bugs in your backend.

Actually, as I state in another email, the bug hits all platforms,
what matters is that the pointers which become invariants in loop have
the high bit set or not.  Loop blindly turns signed comparisons into
unsigned ones when IV'ing integer comparisons into pointer based ones
used as loop test conditions, the signedness of the compare/branch in
the RTL is not changed to reflect this fact.  This is all over loop.c
and it's a mess.

In these tests, a pointer reference to the stack frame gets IV'd, so
depending upon whether the stack pointer has the most significant bit
set or not, you'll see the bug or you won't.

Later,
David S. Miller
davem@dm.cobaltmicro.com