🚀 go-pugleaf

------- Start of forwarded message -------
From: kevinc@kpc.com
Subject: gcc v2.3.3 bug
To: bug-g++@prep.ai.mit.edu
Cc: kevinc@solman.kpc.com
Date: Tue, 19 Jan 93 17:17:52 -0800

   I have found what I consider to be a bug in the optimizer for gcc.  I
realize that the issue of whether something is a bug is not always clear
when talking about a compiler's optimization.  One can always argue about
how far the optimizer should go.  I am calling this a bug since code is
generated which does absolutely nothing and it seems that the compiler
has ample information to avoid the behavior.

   What I found is a case where the optimizer does a very good job of
unrolling a loop to the point where it knows the result. It then iterates
the loop anyway.

   By the way, I am not just trying to cause trouble.  I have found a true
bug which causes the compiler to crash with the message "Internal compiler
error" when the -funroll-loops flag is set.  I am trying to reduce the
program to the smallest case which reproduces the bug.  In so doing I found
the bug that I am reporting now.

Machine: Sun Sparcstation 2
OS:      SunOS 4.1.3
GCC:     2.3.3

C++ source code (test.cc)
- ------------------------
#include <stdio.h>

main () {
   int i = 0 ;
   for (int j = 0; j < 500000; j++) {
      i += 1 ;
      }
   printf ("sums = %d\n", i) ;
   }
- ------------------------

I compile the above program with the command:

g++ -S -O2 -funroll-loops test.c

Assembler output (test.s)
- ------------------------
gcc2_compiled.:
.text
   .align 8
LC0:
   .ascii "sums = %d\12\0"
   .align 4
   .global _main
   .proc 04
_main:
   !#PROLOGUE# 0
   save %sp,-136,%sp
   !#PROLOGUE# 1
   call ___main,0
   nop
   mov 0,%o1
   sethi %hi(499999),%o0
   or %o0,%lo(499999),%o0
   add %o1,10,%o1
L26:
   cmp %o1,%o0
   ble,a L26
   add %o1,10,%o1
   sethi %hi(LC0),%o0
   or %o0,%lo(LC0),%o0
   sethi %hi(500000),%o1
   call _printf,0
   or %o1,%lo(500000),%o1
   ret
   restore %g0,0,%o0
- -----------------

The following section from above seems to be totally unneeded.:
   mov 0,%o1
   sethi %hi(499999),%o0
   or %o0,%lo(499999),%o0
   add %o1,10,%o1
L26:
   cmp %o1,%o0
   ble,a L26
   add %o1,10,%o1

Note that the compiler has already determined the result of the loop
(500000) and is using it as a constant parameter to printf.  Surely
it has enough information to avoid the loop altogether.

Please acknowledge receipt of this message.  Also I would like to
remain informed of the status of this bug as it passes through your
system if that is possible.

Kevin Cameron
kevinc@kpc.com

------- End of forwarded message -------

--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Mountain View, CA                              +1 415 903 1400
                     ``In a cruel and imperfect world,'' says critic Rex Reed,
 ``[Audrey Hepburn] was living proof that God could still create perfection.''