Bug 11243
| Summary: | Current git fails to compile (gcc 3.4.4) | ||
|---|---|---|---|
| Product: | Platform Specific/Hardware | Reporter: | Rafael J. Wysocki (rjw) |
| Component: | i386 | Assignee: | platform_i386 |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | bunk, dhaval, horms, jeremy, mingo |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | commit d8d5900ef8afc562088f8470feeaf17c4747790f | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 11167 | ||
| Attachments: | x86: work around gcc 3.4.x bug | ||
|
Description
Rafael J. Wysocki
2008-08-03 14:36:55 UTC
Caused by: commit d8d5900ef8afc562088f8470feeaf17c4747790f Author: Jeremy Fitzhardinge <jeremy@goop.org> Date: Wed Jun 25 00:19:13 2008 -0400 x86: preallocate and prepopulate separately I think we're calling the resolution on this one "use a non-buggy compiler". There's nothing wrong with the code, and the compiler is outright crashing here. If it crashes on this code, I wouldn't be very confident in its other generated code. I haven't seen a comment from Dhaval as to whether this solution works for him or not. Dhaval has requested to add this report to the regression list. I have not seen any resolution marking gcc v3.4.4 as broken. If that is going to be the resolution, its fine, please go ahead and mark it. I asked for it to be tracked so that it does get marked as bad. Thanks Rafael Well, the compiler is by definition broken, because it crashed. The compiler should never crash, regardless of input. The problem is that the code correct, and it's unclear what one needs to do to it to make the compiler not crash. And even if it didn't crash, how can one be sure that 1) it's generating good code, and 2) a future code change won't break it again? Also, given that there's only been a single report of this problem, I'm guessing this isn't a very widespread compiler version. I'm guessing from the version that it's gcc-3.4.4-2 from a RHEL4 release. It looks like the current RHEL4 compiler is 3.4.6. So, I think the only resolution here is to say that gcc-3.4.4-2 is broken, and update to something newer. If the problem reoccurs on more compilers, then reopen the bug and we'll need to address that. I am OK with the resolution to mark gcc-3.4.4 broken (I would try out a later version of the 3.4 series, but its a pain to build gcc and much easier to install Fedora 9 which had a working gcc :-) ) A side question, how do you mark the compiler as broken and inform other users? (In reply to comment #6) > I am OK with the resolution to mark gcc-3.4.4 broken >... Is gcc 3.4.4 broken or only some Redhat fork of gcc 3.4.4? > A side question, how do you mark the compiler as broken and inform other > users? The most we could do is to add an #error with a message. This makes sense if a gcc version is knwon to miscompile the kernel, but in this case there's nothing we can do to inform users. It turns out this is a general problem with gcc 3.4.x. I posted a patch to work around the problem. Created attachment 17159 [details]
x86: work around gcc 3.4.x bug
Handled-By : Jeremy Fitzhardinge <jeremy@goop.org> Patch : http://lkml.org/lkml/2008/8/8/349 fixed by commit cf3e50501259f9a7cb108a69c3e1b912135628f6 |