Re: egcs 1.1 and bugs

[Jeffrey A Law <law at cygnus dot com>]

  In message <m0yurrq-000266C@ocean.lucon.org>you write:
  > I don't quite understand what is going on. But something is wrong.
  > 
  > 1. For gcse.c, we have
  > 
  > 	block head
  > 	...
  > 	call foo/set memory
  > 	...
  > 	block end
  > 
  > 	block head
  > 	...
  > 	set reg MEM(addr)
  > 	...
  > 	block end
  > 
  > Since there is no memory set in the second block, gces thinks it is
  > safe to optimize MEM(addr). But in fact, the mem set insn in the
  > previous block may change MEM(addr).
It's not that simple.  It depends on the flow relationships between
the various blocks.

Can you provide a testcase?  I don't know the x86 well enough to be
able to debug the problem in any kind of reasonable timeframe.  Even
a large function is OK if you can point out the instructions which
are incorrectly optimized.

You've already debugged the problem, so presumably you know what
function is being mis-compiled and exactly what instructions are
mis-compiled.  Similarly for the sched bug.


  > 2. For sched.c, we have
  > 
  > 	set MEM(add1) reg
  > 	set reg MEM(addr2)
  > 
  > sched2 thinks "set MEM(add1) reg" has higher cost than
  > "set reg MEM(addr2)". It reorder it to:
  > 
  > 	set reg MEM(addr2)
  > 	set MEM(add1) reg
  > 
  > Although addr1 and addr2 look nothing in common, in fact, they have
  > the same value. That is a bug in sched2. Maybe a better aliase
  > analysis can help here.
"higher cost?"  We'd have to have a testcase for this too.   This could
be a bug in the alias code or in libg++ itself.  We won't know for sure
until we get a testcase.  Again, I'm not x86 savvy enough to debug
the problem and create a testcase.