hppa gcc bug?

Looks like there's a strength-reduce optimization bug in g++-3.0.2 on hppa....

Trying to compile qt-x11 gives a segmentation fault when compiling src/kernel/qurl.cpp. (willy and lamont also saw this I believe...). Turning off strength-reduction (-fno-strength-reduce) allows the file to compile to completion.

It's dying inside a loop_iterations call, but I don't know enough to say why...

Can someone more knowledgable please take a look?

Preprocessed source attached. Compilation flags:

g++ -D_REENTRANT -DQT_THREAD_SUPPORT -c -I/usr/X11R6/include -I/usr/src/new/qt-x11-2.3.2/include -I/usr/X11R6/include -pipe -fno-exceptions -O2 -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -fPIC -DQT_BUILTIN_GIF_READER=1 -DQT_XFT -o kernel/qurl.o kernel/qurl.cpp

This is using the latest binutils/gcc that are in the Debian archive. (binutils 20011021 and gcc 3.0.2 w/ Alan's patches)

sh-2.05# gcc -v
Reading specs from /usr/lib/gcc-lib/hppa-linux/3.0.2/specs Configured with: ../src/configure -v --enable-languages=c,c++,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --with-cpp-install-dir=bin hppa-linux
Thread model: posix
gcc version 3.0.2 (Debian)

sh-2.05# ld -v
GNU ld version 2.11.92.0.10 20011021 Debian/GNU Linux

randolph

   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

For those reading this on gcc-patches, there's a .ii at
http://lists.parisc-linux.org/pipermail/parisc-linux/2001-November/014491.html
This is with hppa-linux-gcc based on 3.0.2 20011019.

Program received signal SIGSEGV, Segmentation fault. 0x8187803 in loop_iterations (loop=0x83840f4)

    at /src/parisc/gcc_new/gcc/unroll.c:3509
(gdb) p debug_rtx (temp)
(jump_insn 2390 2389 2391 (addr_diff_vec:DI (label_ref:SI 2389)
        [ 
            (label_ref:SI 1998)
            (label_ref:SI 2392)
            (label_ref:SI 2392)
            (label_ref:SI 2392)
            (label_ref:SI 2045)
            (label_ref:SI 2093)
            (label_ref:SI 2141)
            (label_ref:SI 2189)
            (label_ref:SI 2237)
            (label_ref:SI 2285)
            (label_ref:SI 2333)
        ] 
        (const_int 0 [0x0])
        (const_int 0 [0x0])) -1 (nil)
    (nil))

Making a wild stab at a fix, which isn't likely to be ideal as I don't know this area of gcc. /mumble Probably should iterate over the elements of the addr_diff_vec, or something. /nomumble

* unroll.c (loop_iterations): Don't segfault on ADDR_DIFF_VEC.

@@ -3506,13 +3506,16 @@ loop_iterations (loop)
 
       do
 	{
-	  if (GET_CODE (temp) == JUMP_INSN
-	      /* Previous unrolling may have generated new insns not covered
-		 by the uid_luid array.  */
-	      && INSN_UID (JUMP_LABEL (temp)) < max_uid_for_loop
-	      /* Check if we jump back into the loop body.  */
-	      && INSN_LUID (JUMP_LABEL (temp)) > INSN_LUID (loop->top)
-	      && INSN_LUID (JUMP_LABEL (temp)) < INSN_LUID (loop->cont))
+	  if (GET_CODE (temp) != JUMP_INSN)
+	    continue;
+	  if (/* It's an addr_diff_vec.  */
+	      JUMP_LABEL (temp) == 0
+	      || (/* Previous unrolling may have generated new insns
+		     not covered by the uid_luid array.  */
+		  INSN_UID (JUMP_LABEL (temp)) < max_uid_for_loop
+		  /* Check if we jump back into the loop body.  */
+		  && INSN_LUID (JUMP_LABEL (temp)) > INSN_LUID (loop->top)
+		  && INSN_LUID (JUMP_LABEL (temp)) < INSN_LUID (loop->cont)))
 	    {
 	      if (loop_dump_stream)
 		fprintf (loop_dump_stream,