>>> On Mon, 20 Jul 2009, Marc Dionne wrote:>>>>>> Hmm. This sounds more like the binutils bug that people had. Sounds like>>> an assembler bug if the *.o file ends up being empty or at some fixed>>> size. If it was cc1 that fails, I'd expect to not see an *.o file at all,>>> since it didn't generate good assembly.>>>>>> In fact, your behavior sounds like the thing that produces the *.o files>>> core-dumped or died for other reasons, and had a 64kB buffer that either>>> got flushed or not. That would explain the "zero or exactly 64kB" size.>>>>>> It could be ccache too, of course.>>>> Actually in my case it turns out that it is ccache after all - if I remove it>> from the picture everything is fine. If I re-enable it, even with a clean>> cache, I get the problem.>>>> It might just be a coincidence that it's triggered by the -fwrapv change.>> Ok, so this is getting ridiculous. Do we have _three_ different kernel> issues going on at the same time, all subtly related to tools issues> rather than the kernel source tree itself?>> That's just completely bizarre.>> So right now we have:>> - Krzysztof Oledzki: the only one who so far has really pinpointed it to> the -fwrapv change itself.>> It would be good to really double-check that this is not about ccache,> since Marc apparently gets a good kernel without ccache, and -fwrapv> seems to be involved.

There is no ccache configured in my systems and the same problem appears on a different servers (both i386 and x86-64). However, the configs are very similar and the hardware is nearly identical.

I'm pretty sure the only different between bootable and unbootable kernel is that fwrapv vs strict-overflow change.