On Sun, Jan 15, 2012 at 7:14 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > 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. thanks > > 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
-- Regards, Zhi Yong Wu
