Re: Qemu and GCC-3.4 on powerpc

[Gabriel Paubert <paubert@iram.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

static inline void stl(void *ptr, int v) {
    __asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*(unsigned long *)ptr) : "r" (v), "r" (ptr));
}

int main () {
  extern unsigned long *sp, *u_platform;
  extern char *k_platform;

  stl(sp, (unsigned long)(0)); 
  stl(sp+1, (unsigned long)(0));

  if (k_platform)
    stl(sp, (unsigned long)(15)); 

  stl(sp+1, (unsigned long)((unsigned long) u_platform));
  return 0;
}

	.file	"bug.i"
	.section	".text"
	.align 2
	.globl main
	.type	main, @function
main:
	lis 11,k_platform@ha
	lis 9,sp@ha
	lwz 0,k_platform@l(11)
	lwz 10,sp@l(9)
	li 9,15
	cmpwi 7,0,0
	beq- 7,.L7
#APP
	stwbrx 9,0,10
#NO_APP
	lis 9,u_platform@ha
	addi 11,10,4
	lwz 0,u_platform@l(9)
#APP
	stwbrx 0,0,11
#NO_APP
	li 3,0
	blr
.L7:
	lis 9,u_platform@ha
	stw 8,0(10)
	addi 11,10,4
	lwz 0,u_platform@l(9)
#APP
	stwbrx 0,0,11
#NO_APP
	li 3,0
	blr
	.size	main,.-main
	.section	.note.GNU-stack,"",@progbits
	.ident	"GCC: (GNU) 3.4.6 (Debian 3.4.6-1)"