Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455038 - 5.2 GCC bug - 255.vortex crashes
Summary: 5.2 GCC bug - 255.vortex crashes
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gcc
Version: 5.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jakub Jelinek
QA Contact: Petr Muller
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-11 16:18 UTC by Alan Matsuoka
Modified: 2018-10-20 02:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-14 14:18:58 UTC
Target Upstream Version:


Attachments (Terms of Use)
core file (deleted)
2008-07-11 16:18 UTC, Alan Matsuoka
no flags Details
vortex_base.gcc4-dbg-opt (deleted)
2008-07-11 16:19 UTC, Alan Matsuoka
no flags Details

Description Alan Matsuoka 2008-07-11 16:18:18 UTC
SEG,

I received the following bug report from Goldman; I don't have the code in
question (from SPEC's CPU integer benchmark) so it's hard to test. We (as in
RHT) should have the code somewhere.

:: SEG Escalation Template ::

State the problem

  1. Provide time and date of the problem

anytime.
 As we discussed, I stumbled across a bug in the gcc 4.1.2 that we have with
RHEL5.   This might have been fixed in a later version, but would be a really
bad thing for us if we are going to start pushing people to RHEL5.

Anyway, I hit this in the 255.vortex test of SpecINT 2000.   The code in
question compiles fine under –O1 or –O2, but with –O2 it crashes :-(

I was able to narrow it down to the instruction scheduler.  If I compile –O2, I
get a crash.   If I compile
-O2 –fno-schedule-insns –fno-schedule-insns2
then all is well


  2. Indicate the platform(s) (architectures) the problem is being reported against.

x86/x86_64

  3. Provide clear and concise problem description as it is understood at the
time of escalation
         * Observed behavior

problem compiling the vortex test in the SPEC CPU benchmark.

         * Desired behavior

successful compile.

  4. State specific action requested of SEG

unless you have a great inkling, please escalate to BZ. This is not an open
source benchmark, per se, although if you have it available it is distributed in
source form. As we are members of SPEC, we should have copies available somewhere.

  5. State whether or not a defect in the product is suspected

yes, I'd guess. But hard to verify without sources.

         * Provide Bugzilla if one already exists

x

  6. If there is a proposed patch, make sure it is in unified diff format (diff
-pruN)

x

  7. Refrain from using the word "hang", as it can mean different things to
different people in different contexts. Use a better and more specific
description of your problem.

x

  8. This is especially important for severity one and two issues. What is the
impact to the customer when they experience this problem?
         * For example: "This system houses our accounts payable database. When
the system crashes we are unable to process payroll, and other payable
functions. This is especially critical as we approach end of our quarter."

The customer is using SPEC CPU for benchmarking RHEL 5 as part of a planned
rollout of 5.2. This is holding back testing and, in small part, the eventual
release.


Issue escalated to Support Engineering Group by: ahecox.

Comment 1 Alan Matsuoka 2008-07-11 16:18:18 UTC
Created attachment 311601 [details]
core file

Comment 2 Alan Matsuoka 2008-07-11 16:19:44 UTC
Created attachment 311602 [details]
vortex_base.gcc4-dbg-opt

Comment 3 Jakub Jelinek 2008-07-11 16:26:57 UTC
Does the problem go away with -O2 -fno-strict-aliasing?  Perhaps the test
violates C aliasing rules.  Vlad, do you remember if vortex has these issues?
Several of the SPEC tests have these kind of bugs (e.g. perlbmk if I remember
well), but I don't know if vortex does too or not.

Comment 4 Vladimir Makarov 2008-07-14 02:10:25 UTC
Vortex is not ANSI C standard program.  It really violates C aliasing rule.  GCC
from SPEC2000 violates them too but vortex has the biggest probability to be
broken without -fno-strict-aliasing.  That is my observation of SPEC2000
benchmarking during several years of GCC development.



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