This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

2.95 compiler bug with optimization level > 0...


Hi,

Due to the proprietary nature of this code, I am unable to include a test
case.  Also, it was not possible to construct a smaller test case which exhibits 
this bug.  It apparently has to be within the context of the entire source code.
Below it the bug report.  Any help would be greatly appreciated!!!!!!!!!!!!!!!!
Note,  compiler rev, gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) works.


--- bug report ---
compiler version: gcc version 2.95 19990728 (release).  Also tried 2.95.2.
platform: SunOS 5.5.1, UltraSPARC-IIi-Engine
options:  -I. -Wall -O3 -c <filename.cc> 


   if(!qualifier)
   {
      while((array[4] & 0x8000) == 0)
      {
// dummy printf("what's going on\n");
         for(k = 4; k != 0; k--)
         {
//          array[k] = (UINT16)((array[k] << 1) | (array[k-1] & 0x8000));
            array[k] = (UINT16)((array[k] << 1) | ((array[k-1] & 0x8000) >> 15));
         }
         array[0] = (UINT16)(array[0] + array[0]);
         count--;
      }
   }

This code is simply shifting left an 80-bit value, stored in an array as 5 16-bit 
values, until the msb is set.  The program flows thru this code twice.  The first 
time everything worked fine.  The second time around, array[4] is 0x4000 and all 
other array values are 0 when we first enter the while loop.  So, at the end of 
the first iteration, in the while loop, array[4] == 0x8000.  I actually saw this 
in my debug.  However, the expression in the while statement resolves to TRUE for 
some reason(BUG) and we go through the loop again.  Then, the 1 in the 
msb(0x8000 in array[4]) gets shifted off the end and now the entire 80-bit value 
is all 0's.  So, we will never again get a 1 in the msb to break us out of the 
loop...hung in an infinite loop.  The real kicker is if you put a printf statement 
where I've indicated above, everything works fine.  Also, if you compile with 
optimization level 0, it does not fail.  Apparantly the bug is somehow related 
to the compiler incorrectly optimizing this case where the for statement 
immediately follows the while statement.  Because, when you put the printf 
statement between them, everything works fine.


-- 
********************************************************************************
Brad Perry                             ______  
E-mail: brad.perry@amd.com             \___  |         Advanced Micro Devices
Phone:  (512) 602-6863                 /|  | |         5900 E. Ben White Blvd.
FAX:    (512) 602-6970                | |__| |         Mail Stop 615
WATS:   (800) 538-8450(x56863)        |___/ \|         Austin, TX 78741

********************************************************************************


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]