Bug 15354 - wrong code regression on enum test
Summary: wrong code regression on enum test
Status: RESOLVED DUPLICATE of bug 16372
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-09 20:35 UTC by senor_fjord
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description senor_fjord 2004-05-09 20:35:43 UTC
The following code compiles fine on g++ 3.3.3 and 3.2.2, but does not on 3.4.0 or 3.4.1 release 
20040502.  I'm not sure if this is related to bug 15069 or not.  The code example is below.  When 
compiled with 3.4, it executes the print statement.  This bug only occurs when optimization (-O1, -O2, 
or -O3) is enabled.

int printf(char *, ...);

enum my_enum_e {
  zero      = 0,
  one       = 1,
  two       = 2,
  three     = 3,
  four      = 4,
  five      = 5,
  six       = 6,
  seven     = 7,
  eight     = 8,
  nine      = 9,
  ten       = 10,
  eleven    = 11,
  twelve    = 12,
  thirteen  = 13,
  fourteen  = 14,
  fifteen   = 15,
  sixteen   = 16,
  seventeen = 17,
  eighteen  = 18,
  nineteen  = 19,
  numbers   = 20
};

my_enum_e ret_nineteen() {
  return nineteen;
}


int main() {
  my_enum_e enm = ret_nineteen();

  if (enm == one      || enm == two      || enm == three   ||
      enm == four     || enm == five     || enm == six     ||
      enm == seven    || enm == eight    || enm == nine    ||
      enm == ten      || enm == eleven   || enm == twelve  ||
      enm == thirteen || enm == fourteen || enm == fifteen ||
      enm == sixteen)
    printf("shouldn't print");

  return 0;
}


The generated assembly is the following.  The test at EIP 804844f isn't correct if I'm reading the code 
right.

08048434 <ret_nineteen()>:
 8048434:       55                      push   %ebp
 8048435:       89 e5                   mov    %esp,%ebp
 8048437:       b8 13 00 00 00          mov    $0x13,%eax
 804843c:       5d                      pop    %ebp
 804843d:       c3                      ret    

0804843e <main>:
 804843e:       55                      push   %ebp
 804843f:       89 e5                   mov    %esp,%ebp
 8048441:       83 ec 08                sub    $0x8,%esp
 8048444:       83 e4 f0                and    $0xfffffff0,%esp
 8048447:       83 ec 10                sub    $0x10,%esp
 804844a:       e8 e5 ff ff ff          call   8048434 <ret_nineteen()>
 804844f:       85 c0                   test   %eax,%eax
 8048451:       74 0c                   je     804845f <main+0x21>
 8048453:       c7 04 24 48 85 04 08    movl   $0x8048548,(%esp,1)
 804845a:       e8 f9 fe ff ff          call   8048358 <_init+0x38>
 804845f:       b8 00 00 00 00          mov    $0x0,%eax
 8048464:       c9                      leave  
 8048465:       c3                      ret    
 8048466:       90                      nop    
 8048467:       90                      nop
Comment 1 Andrew Pinski 2004-05-09 20:46:19 UTC
This is a dup of bug 15069 as fold is what is cause to create the bad code and it is happening in the 
same spot.

*** This bug has been marked as a duplicate of 15069 ***
Comment 2 Andrew Pinski 2004-07-27 23:32:59 UTC
Reopening to mark as a dup of a differnet bug.
Comment 3 Andrew Pinski 2004-07-27 23:33:34 UTC

*** This bug has been marked as a duplicate of 16372 ***