Bug 455038
| Summary: | 5.2 GCC bug - 255.vortex crashes | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Alan Matsuoka <alanm> | ||||||
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Petr Muller <pmuller> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 5.2 | CC: | ohudlick, tao, vmakarov | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-07-14 14:18:58 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 311601 [details]
core file
Created attachment 311602 [details]
vortex_base.gcc4-dbg-opt
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. 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. |
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.