Code gen error on PowerPC
Jeffrey A Law
law@hurl.cygnus.com
Mon Mar 1 16:02:00 GMT 1999
In message < 4.2.0.25.19990301224624.03f0e420@mail.lauterbach.com >you write:
> At 19:03 01.03.99 , Richard Henderson wrote:
> >On Mon, Mar 01, 1999 at 06:52:59PM +0100, Franz Sirl wrote:
> >> Ugh, that's not the answer I wanted to hear :-(. This probably means I h
> ave
> >> to do an extensive debugging session again... Isn't there any chance tha
> t
> >> you fixed a bug without knowing? :-)
> >
> >I suppose it's possible -- a lot of code changed. It seems more
> >likely that differing combine_givs heuristics merely hid the problem.
> >
> >> Any hints on what I should look at first during debugging?
> >
> >If I understood your explanation right, you've got a GIV being
> >recognized that isn't. I'd start by finding out why that's so.
> >
> >You'll want to put a breakpoint in strength_reduce, right before
> >the call to general_induction_var. Conditionalize it on the insn
> >that contains the GIV. Likely the meat of the problem will be in
> >simplify_giv_expr, cases REG and default.
>
> The underlying problem seems to be that the following hunk of code (it is
> entered with auto_inc_opt is -1, tv->insn is insn 33, v->insn is insn 71)
> around line 4210 generates insn 158 and inserts it at the beginning of the
> _inner_ loop instead of the outer loop:
[ ... ]
OK. I think this reinforces Richard's theory that something is being
recognized as a general induction variable that really is not a general
induction variable for the inner loop.
So, I think you need to be looking into the calls to general_induction_var
like Richard suggested.
Some call to that function is returning a nonzero value when it should be
returning zero if Richard's theory is correct.
jeff
More information about the Gcc-bugs
mailing list