Re: [Qemu-devel] [PATCH 1.3] build: compile translate.o at -O1 optimization

[Paolo Bonzini]

Il 27/11/2012 14:46, Peter Maydell ha scritto:
> On 27 November 2012 13:45, Gerd Hoffmann <address@hidden> wrote:
>> On 11/27/12 14:24, Peter Maydell wrote:
>>> This is a well known bug in old gcc (ie fixed in 4.5, 4.6 and
>>> trunk a year ago). Use a newer gcc, or a 64 bit build system
>>> with a reasonable amount of RAM, or as a workaround apply some
>>> suitable compiler flags by passing configure
>>> '--extra-cflags=-fno-var-tracking'. This patch definitely
>>> shouldn't be applied as we shouldn't be hampering the majority
>>> for the benefit of old broken systems.
>>
>> It isn't that simple.  It's Fedora 17 with gcc 4.7.2 which runs oom
>> while compiling translate.c
> 
> In that case it is a new (or regressed) gcc bug and we should be
> pursuing it with the upstream gcc folk. We still shouldn't be
> putting random workarounds in our configure script.

Sure we should, but we're also one week from release.  Pretty sure a lot
of people will compile QEMU on a machine with <2GB and fail; the choice
is between documenting the problem and workaround in the release
information, or doing it for everyone in the Makefile.

Unfortunately, this one is not fixed by settling for worse debug
information, and it happens with GCC 4.7.2 (latest stable).  It is fixed
in GCC trunk, but it is also possible that it is just latent because I
found that several GCC switches fix it:

* -fPIE is what causes it.  Removing it obviously fixes it, but I'm not
sure it is a good idea (does it break linux-user self-virtualization?)

* -fno-gcse turns off the pass that explodes, and fixes it

* -fno-tree-pre turns off a similar but unrelated pass, but also fixes
it (found by chance because I confused it with -fno-gcse :)).

I think -fno-gcse is a valid workaround, and better than this patch.

Paolo