Bug 137109 - compiling with O2 caused a tight loop
compiling with O2 caused a tight loop
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc3 (Show other bugs)
3.0
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-25 16:09 EDT by satish
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-25 16:27:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description satish 2004-10-25 16:09:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9)
Gecko/20020408

Description of problem:
When compiling the following code as

  gcc -g -O2 a.c -o a 

Gets stuck in the 'for' loop


void
pan_generic_mem_set(
  void          *s,
  int            p,
  int    size)
{
  char *temp = (char *) s;
  while(size > 0) {
    *temp = p;
    temp++;
    size--;
  }
}


int main() {
  char name[10];
  char c;
  pan_generic_mem_set(name,0, sizeof(name));
  for (c = (char)1; c!='\0' ; c++) {
    name[0] = c;
    name[1] = c;
    name[2] = c;
    name[3] = c;

  }
}

The assembly listing is somehow missing the cmp4 instruction

(gdb) disassemble main
Dump of assembler code for function main:
0x4000000000000690 <main+0>:    [MMB]       alloc r34=ar.pfs,7,4,0
0x4000000000000691 <main+1>:                adds r12=-16,r12
0x4000000000000692 <main+2>:                nop.b 0x0
0x40000000000006a0 <main+16>:   [MFI]       mov r32=r1
0x40000000000006a1 <main+17>:               nop.f 0x0
0x40000000000006a2 <main+18>:               mov r33=b0;;
0x40000000000006b0 <main+32>:   [MMB]       adds r36=16,r12
0x40000000000006b1 <main+33>:               mov r37=r0
0x40000000000006b2 <main+34>:               nop.b 0x0
0x40000000000006c0 <main+48>:   [MIB]       mov r38=10
0x40000000000006c1 <main+49>:               mov.i r35=ar.lc
0x40000000000006c2 <main+50>:               br.call.sptk.many
b0=0x4000000000000640                  <pan_generic_mem_set>;;
0x40000000000006d0 <main+64>:   [MII]       nop.m 0x0
0x40000000000006d1 <main+65>:               mov.i ar.lc=-50
0x40000000000006d2 <main+66>:               mov r1=r32
0x40000000000006e0 <main+80>:   [MMI]       mov r37=1;;
0x40000000000006e1 <main+81>:               addl r36=72,r1
0x40000000000006e2 <main+82>:               nop.i 0x0;;
0x40000000000006f0 <main+96>:   [MFB]       ld8 r36=[r36]
0x40000000000006f1 <main+97>:               nop.f 0x0
0x40000000000006f2 <main+98>:               br.call.sptk.many
b0=0x4000000000000400                  <_init+272>;;
0x4000000000000700 <main+112>:  [MMI]       nop.m 0x0
0x4000000000000701 <main+113>:              mov r1=r32
0x4000000000000702 <main+114>:              mov r15=49
0x4000000000000710 <main+128>:  [MMI]       nop.m 0x0
0x4000000000000711 <main+129>:              adds r17=18,r12
0x4000000000000712 <main+130>:              adds r16=19,r12;;
0x4000000000000720 <main+144>:  [MMB]       adds r14=1,r15
0x4000000000000721 <main+145>:              st1 [r17]=r15
0x4000000000000722 <main+146>:              nop.b 0x0
0x4000000000000730 <main+160>:  [MMI]       st1 [r16]=r15;;
0x4000000000000731 <main+161>:              nop.m 0x0
0x4000000000000732 <main+162>:              sxt1 r14=r14;;
0x4000000000000740 <main+176>:  [MIB]       nop.m 0x0
0x4000000000000741 <main+177>:              mov r15=r14
0x4000000000000742 <main+178>:              br.cloop.sptk.few
0x4000000000000720 <m                 ain+144>;;
0x4000000000000750 <main+192>:  [MMI]       nop.m 0x0
---Type <return> to continue, or q <return> to quit---
0x4000000000000751 <main+193>:              mov r8=r14
0x4000000000000752 <main+194>:              mov.i ar.pfs=r34
0x4000000000000760 <main+208>:  [MII]       nop.m 0x0
0x4000000000000761 <main+209>:              mov.i ar.lc=r35
0x4000000000000762 <main+210>:              mov b0=r33
0x4000000000000770 <main+224>:  [MMB]       nop.m 0x0
0x4000000000000771 <main+225>:              adds r12=16,r12
0x4000000000000772 <main+226>:              br.ret.sptk.many b0;;
End of assembler dump.

(gdb)



redhat-release/uname 
Red Hat Enterprise Linux AS release 3 (Taroon Update 3)

Linux tower 2.4.21-20.EL #1 SMP Wed Aug 18 20:30:22 EDT 2004 ia64 ia64
ia64 GNU/Linux


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Run the attached program
2.
3.
    

Actual Results:  The for loop does not break

Expected Results:  The loop should have broken

Additional info:
Comment 1 Jakub Jelinek 2004-10-25 16:27:19 EDT
When char is signed (it is on ia64), then your testcase invokes
undefined behaviour and what GCC did with it is perfectly fine
implementation of undefined behaviour.
Integer overflow is defined for unsigned integers only in ISO C.
If you compile your program with -O2 -funsigned-char (or change
c's type to unsigned char), it will work as you expect.

Note You need to log in before you can comment on or make changes to this bug.