Re: target/5169: Bug in pa-risc gcc optimizer

[law at redhat dot com]

  > Thanks, your patch solves all of my problems! That means:
  > 
  >     target/5169: Bug in pa-risc gcc optimizer
  >     target/5185: Segmentation error in final.c
  > 
  > and as a bonus also this one:
  > 
  >     optimization/5264: Possible optimization bug at -O2 on HP-UX
  > 
  > 
  > With your patch applied to the snapshot gcc-20011231 I can bootstrap 
  > a working compiler gcc 2.95.3:
  > 
  >   ../gcc-20011231/configure --prefix=/... --enable-languages=c,c++ 
  >     --with-gnu-as --with-as=/opt/net/local/bin/as
  >   gmake bootstrap CFLAGS=-O1
  > 
  > Please note that if you are bootstrapping from gcc, then it is essencial
  > to make the first step of the bootstrap with optimizer level set to 
  > something lower than 2 (-O1 works).
  > 
  > With the native HP compiler this is probably not nessary.
  > 
  > Thanks, your patch might just solve years of mysterious problems! Now I
  > just 
  > have to build xemacs, to see if this solves the strange craches.
Be very very careful thinking all is well with this problem, particularly
if you're working with the current development sources.

First, the testcase mentioned in the PR does not correspond to the RTL
fragments Alan posted.  How do I know this?  Well, the testcase as a local
variable named "operands".  Local variables are in registers or in stack
slots.

However, the RTL in the bug shows this:

> (insn 12 10 15 (set (reg/v:SI 94)
>         (mem/s:SI (lo_sum:SI (reg/f:SI 95)
>                 (const:SI (plus:SI (symbol_ref:SI ("operands___0"))
>                         (const_int 4 [0x4])))) 2)) 68 {*pa.md:2088}

That would be consistent with operands being declared as a "static int", not
an automatic variable.

This (of course) was rather confusing when I was trying to double-check
Alan's analysis.  Luckily after further investigation I can confirm that
while the RTL and testcase don't match it's not that important (except for
the poor bastard trying to reproduce Alan's results).

To further confuse things, the bug is currently masked by unrelated changes
in the compiler (code which tries to normalize the order of arguments in
the comparison to make later code simpler).  


jeff