Messages in this thread |  | | Date | Mon, 20 Jul 2009 16:56:43 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Linux 2.6.27.27 |
| |
On Mon, 20 Jul 2009, Marc Dionne wrote: > > I might be seeing a slightly different bug, but in case it's helpful, the > behaviour here on Fedora rawhide with gcc-4.4.0-14.x86_64 and > binutils-2.19.51.0.11-27.fc12.x86_64 is that I get various .o files that come > out as completely empty files (or in one case as a precisely 64K sized file > that gives a "File format not recognized" error"), and the latest 2.6.31-rc > git can't be built at all.
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.
> If I replace -fno-strict-overflow with -fwrapv in Makefile everything builds > and runs fine.
.. and this is just really really odd. If it was the cc1 front-end that does that with a bad optimization, I'd expect more visible turds. But on the other hand, if it's the binutils, then I don't see why -fwrapv would matter. Some front-end options get passed down to the assembler, but I would definitely not expect -fwrapv/-fno-strict-overflow to be one of those.
Linus
|  |