Re: Qemu and GCC-3.4 on powerpc

[Gabriel Paubert <paubert at iram dot es>]

On Sun, Apr 09, 2006 at 02:45:04PM +0200, Dieter Schuster wrote:
> Tach auch!
> 
> Am Fr, den 31 März 2006, schrieb Alan Modra:
> > On Tue, Mar 28, 2006 at 12:00:47PM +0200, Gabriel Paubert wrote:
> > > On Tue, Mar 28, 2006 at 12:56:13AM +0200, Dieter Schuster wrote:
> > > > If I try to compile qemu with GCC 3.4 without the patch I get the following error:
> > > > 
> > > > qemu-0.8.0/linux-user/elfload.c: In function `load_elf_binary':
> > > > qemu-0.8.0/cpu-all.h:253: error: inconsistent operand constraints in an `asm'
> > > > qemu-0.8.0/cpu-all.h:253: error: inconsistent operand constraints in an `asm'
> > > 
> > > Weird. CC'ed to gcc list despite the fact that the 3.4 branch
> > > is definitely closed. I've not found anything remotely similar
> > > from bugzilla.
> > > 
> > > > 
> > > > But if I copy the function stl_le_p to a seperate file, the function
> > > > will compile with GCC 3.4. 
> > 
> > Check preprocessor output.  My guess is that you have some unexpected
> > substitution.
> > 
> 
> I had now more time, to investigate the error. It seems to be a
> optimization problem. With -O2 -fno-gcse the error disappeared. I have
> made a bug report to gcc. 

Yes, but you sent it to gnats-gcc, which is completely obsolete. You
should use bugzilla. Now the testcase looks really minimal:

http://lists.debian.org/debian-gcc/2006/04/msg00135.html

even if the code looks strange (redundant cast, if without 
braces which confused me at first). This may be the result
of normal macro expansion.

However, I believe that the most serious problem is that you 
use uninitialized local variables (which makes the code invalid). 
I have changed the testcase to the attached file by declaring 
these variables extern (the code is also reformatted to be more 
readable).

Testing here with recent Debian versions of gcc-3.4, 4.0 and 4.1
show that I can' trigger any problem with 4.0 and 4.1, and that 
for gcc-3.4:
- -O1 always works (regardless of -fgcse), which is surprising 
  since I have exactly the same compiler as you.
- -O2 -fno-gcse works
- -O2 (implies -fgcse) fails

In the failure case, the generated code (attached) does not make 
sense: one stwbrx disappears and is mysteriously replaced by an 
stw, the source of which is a register which has never been 
initialized (r8), while I don't see any uninitialized variable
in the source after the small changes I've made.

	Regards,
	Gabriel

Attachment: bug.i
Description: Testcase source code.

Attachment: bug.s-3.4-O2
Description: Testcase assembly output (gcc-3.4 -O2).