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

[law at redhat dot com]

The following reply was made to PR target/5169; it has been noted by GNATS.

From: law@redhat.com
To: Klaus Pedersen <klaus.k.pedersen@nokia.com>
Cc: ext Alan Modra <amodra@bigpond.net.au>, gcc-bugs@gcc.gnu.org,
        luke@stat.umn.edu, gcc-gnats@gcc.gnu.org, Richard.Earnshaw@arm.com,
        gcc-patches@gcc.gnu.org, rodrigc@gcc.gnu.org
Subject: Re: target/5169: Bug in pa-risc gcc optimizer 
Date: Thu, 03 Jan 2002 11:51:08 -0700

   > 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