Bug 39764 - gcc generates incorrect code
Summary: gcc generates incorrect code
Status: CLOSED DUPLICATE of bug 37054
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
(Show other bugs)
Version: 7.0
Hardware: i686 Linux
high
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-05-09 02:55 UTC by Jim Wright
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-09 02:55:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jim Wright 2001-05-09 02:55:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-7.0.1 i686)

Description of problem:
We believe we have found a bug in gcc.  We have been trying to track
down why .../drivers/scsi/sym53c8xx.c driver oopses when initializing
at line 5265, which reads:

        period = (4 * div_10M[0] + np->clock_khz - 1) / np->clock_khz;

We believe the bug is that gcc is generating incorrect code for this:

                if      (f1 < 55000)            f1 =  40000;
                else                            f1 =  80000;

Here is the test code to demonstrate this:

% cat bug.c
int main (int argc, char *argv[])
{
    unsigned f1;

    f1 = (unsigned)argc;

    if (f1 < 5) {
        f1 = 4;
    } else {
        f1 = 8;
    }
    exit (f1);
}

And here are commands to exhibit the problem.

% for i in 0 1 2 3 4 5 6 ; do ln bug.c bug$i.c ; done
% for i in 0 1 2 3 4 5 6 ; do gcc -save-temps -O$i -o bug$i bug$i.c ; done
% for i in 0 1 2 3 4 5 6 ; do ./bug$i 1 2 ; echo $? ; done
% for i in 0 1 2 3 4 5 6 ; do ./bug$i 1 2 3 4 5 6 7 ; echo $? ; done

The level 0 optimization assembly code appears correct.  For level 1 and
above, the compiler emits a long subtract with borrow statement which
leaves EAX either 0 filled or 1 filled, based on the carry flag.

As this is with Red Hat's gcc, I'm not sending this to the gcc.  Versions
with this problem include gcc-2.96-69 and gcc-2.96-81.


How reproducible:
Always

Steps to Reproduce:
follow example above

Additional info:

Comment 1 Matt Wilson 2001-05-09 03:24:20 UTC

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


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