On Sat, Jan 14, 2012 at 3:40 PM, Zhi Yong Wu <zwu.ker...@gmail.com> wrote: > On Mon, Jan 9, 2012 at 9:00 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> On Mon, Jan 9, 2012 at 11:25 AM, Kevin Wolf <kw...@redhat.com> wrote: >>> Am 20.12.2011 17:49, schrieb Stefan Hajnoczi: >>>> On Tue, Dec 20, 2011 at 3:25 PM, Michael Niehren >>>> <902...@bugs.launchpad.net> wrote: >>>>> here we are. Attached the tgz. I am using no spezial distribution, it's a >>>>> self compiled LFS with >>>>> gcc V4.5.1 >>>>> >>>>> Is there a different compiler-call if i use --enable-debug, which then >>>>> works ? >>>> >>>> Richard Sandiford looked at your gcc -fdump-tree-all-details output >>>> and suggests that this bug has been fixed in gcc 4.5.3: >>>> >>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45967 >>>> >>>> Using the most recent gcc should fix the issue you are seeing. >>> >>> Can we add some workaround? Not sure what will work, maybe a simple >>> compiler barrier? >> >> Sure though it seems like a very rare case - OP was running Linux From >> Scratch and hence got the broken gcc. But if someone does a small >> workaround and tests it then that would be nice. > How to do this workaround in qemu since it is one gcc bug?
The problem is that that compiler keeps values in registers across a point where C semantics require that they be reloaded. There are several ways to force a compiler to reload values including a barrier (which Kevin suggested) or the volatile keyword. One of these techniques can probably be used as a workaround, but it would be necessary to check gcc 4.5.1 output to make sure it's effective. I think it's not worth doing unless we think more users will be affected. Unless a distro ships the broken compiler version or it's the latest gcc release that people would build from source, I bet the number of users is very small. Stefan
