Re: Patch causes segv

[Dale Johannesen <dalej at apple dot com>]

On Friday, October 25, 2002, at 03:35  PM, Dale Johannesen wrote:
> The fault is in the doloop code; it runs correctly with 
> -fno-branch-count-reg.
> The problem is this patch (or more accurately, I don't think this patch
> really fixes what it was supposed to fix):
> http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00499.html
> In the case above,
> - len=8, unroll_number=4, abs_inc=2
> - (final-initial) = 7  [this is not known until runtime, obviously, 
> but is done right]
> - the loop should be executed 4 times (with i==1, 3, 5, 7)
> - the preconditioning code does the right thing, executing no 
> iterations prior to the main loop
> - but this computation in this patch, and in the code:
>
> +       t1 = abs_inc * unroll_number;		increment per loop
> +       n = abs (final - initial) / t1;		full loops
> +       n += (abs (final - initial) % t1) != 0;
What I eventually came up with is:

> +       t1 = abs_inc * unroll_number;		increment per loop
> +       n = abs (final - initial + abs_inc-1) / t1;  full loops
> +       n += (abs (final - initial + abs_inc-1) % t1) >= abs_inc  ; 
> partial loops
And this is independent of preconditioning; the preconditioning code 
increments
"initial" as it goes along, so those pre-iterations don't come into the 
above
computation.  For preconditioned loops it should always be true that 
the last
term above works out to 0, but there's no need to test explicitly.

This works for 176.gcc, the small test above, the PR that triggered the 
incorrect patch,
and two other specmarks that displayed the same bug.  I'm running 
bootstrap and test
over the weekend.  If anybody wants to comment on the algorithm, now is 
the time. (I found
this quite confusing; writing down examples helped a lot).