|Summary:||Current git fails to compile (gcc 3.4.4)|
|Product:||Platform Specific/Hardware||Reporter:||Rafael J. Wysocki (rjw)|
|Severity:||normal||CC:||bunk, dhaval, horms, jeremy, mingo|
|Kernel Version:||commit d8d5900ef8afc562088f8470feeaf17c4747790f||Tree:||Mainline|
|Bug Depends on:|
|Attachments:||x86: work around gcc 3.4.x bug|
Description Rafael J. Wysocki 2008-08-03 14:36:55 UTC
Subject : Current git fails to compile Submitter : Dhaval Giani <firstname.lastname@example.org> Date : 2008-07-18 7:55 References : http://marc.info/?l=linux-kernel&m=121636772226303&w=4 Handled-By : Jeremy Fitzhardinge <email@example.com> This entry is being used for tracking a regression from 2.6.26. Please don't close it until the problem is fixed in the mainline.
Comment 1 Rafael J. Wysocki 2008-08-03 14:37:32 UTC
Caused by: commit d8d5900ef8afc562088f8470feeaf17c4747790f Author: Jeremy Fitzhardinge <firstname.lastname@example.org> Date: Wed Jun 25 00:19:13 2008 -0400 x86: preallocate and prepopulate separately
Comment 2 Jeremy Fitzhardinge 2008-08-03 15:06:30 UTC
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.
Comment 3 Rafael J. Wysocki 2008-08-03 15:10:35 UTC
Dhaval has requested to add this report to the regression list.
Comment 4 Dhaval Giani 2008-08-03 21:51:54 UTC
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
Comment 5 Jeremy Fitzhardinge 2008-08-06 11:11:41 UTC
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.
Comment 6 Dhaval Giani 2008-08-06 22:08:03 UTC
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?
Comment 7 Adrian Bunk 2008-08-07 08:27:31 UTC
(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.
Comment 8 Jeremy Fitzhardinge 2008-08-09 17:56:51 UTC
It turns out this is a general problem with gcc 3.4.x. I posted a patch to work around the problem.
Comment 9 Jeremy Fitzhardinge 2008-08-09 17:57:45 UTC
Created attachment 17159 [details] x86: work around gcc 3.4.x bug
Comment 10 Adrian Bunk 2008-08-10 03:29:43 UTC
Handled-By : Jeremy Fitzhardinge <email@example.com> Patch : http://lkml.org/lkml/2008/8/8/349
Comment 11 Adrian Bunk 2008-08-12 11:09:01 UTC
fixed by commit cf3e50501259f9a7cb108a69c3e1b912135628f6