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