[Bug c/21535] New: Empty inline assembly cause the generated code to be wrong?

[Bug c/21535] New: Empty inline assembly cause the generated code to be wrong?

[yhlin at sdesigns dot com]

Two C file (p.c and q.c) attached bellows. With an inline assembly
line (even just a comment), the code sequence is different. As a
result, the function foo() in q.c is working OK but not the foo()
in p.c.

*** Command line ***
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-gcc -v
Reading specs from
/utils/gcc/3.4.3/mipsel-linux-uclibc/i386/lib/gcc/mipsel-linux-uclibc/3.4.3/specs
Configured with:
/home/YH/MIPS/BR/buildroot/toolchain_build_mipsel/gcc-3.4.3/configure
--prefix=/utils/gcc/3.4.3/mipsel-linux-uclibc/i386 --build=i386-pc-linux-gnu
--host=i386-pc-linux-gnu --target=mipsel-linux-uclibc --enable-languages=c,c++
--enable-shared --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--disable-nls --enable-multilib --enable-sjlj-exceptions
Thread model: posix
gcc version 3.4.3

$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-gcc -mno-abicalls
-O2 -c -o p.o p.c
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-objdump -S p.o > p.dasm

$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-gcc -mno-abicalls
-O2 -c -o q.o q.c
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-objdump -S q.o > q.dasm

==== p.c ====

int foo(int x, int y, int z)
{
__asm__ __volatile__ ("/* TEST */\n");
	return((x + y) / z);
}

==== end of p.c ====

==== q.c ====

int foo(int x, int y, int z)
{
// __asm__ __volatile__ ("/* TEST */\n");
	return((x + y) / z);
}

==== end of q.c ====

====> with the inline assembly (p.dasm)

p.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <foo>:
   0:	00851021 	addu	v0,a0,a1
   4:	14c00002 	bnez	a2,10 <foo+0x10>
   8:	0046001a 	div	zero,v0,a2
   c:	0007000d 	break	0x7
  10:	00001012 	mflo	v0
  14:	03e00008 	jr	ra
  18:	00000000 	nop
  1c:	00000000 	nop

====> without the inline assembly (q.dasm)

q.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <foo>:
   0:	00851021 	addu	v0,a0,a1
   4:	0046001a 	div	zero,v0,a2
   8:	14c00002 	bnez	a2,14 <foo+0x14>
   c:	00000000 	nop
  10:	0007000d 	break	0x7
  14:	00001012 	mflo	v0
  18:	03e00008 	jr	ra
  1c:	00000000 	nop

----> assembly file (p.s)

	.file	1 "p.c"
	.section .mdebug.abi32
	.previous
	.text
	.align	2
	.globl	foo
	.ent	foo
	.type	foo, @function
foo:
	.frame	$sp,0,$31		# vars= 0, regs= 0/0, args= 0, gp= 0
	.mask	0x00000000,0
	.fmask	0x00000000,0
#APP
	/* TEST */

#NO_APP
	addu	$2,$4,$5
	div	$0,$2,$6
	bne	$6,$0,1f
	break	7
1:
	mflo	$2
	j	$31
	.end	foo
	.ident	"GCC: (GNU) 3.4.3"

----> assembly file (q.s)

	.file	1 "q.c"
	.section .mdebug.abi32
	.previous
	.text
	.align	2
	.globl	foo
	.ent	foo
	.type	foo, @function
foo:
	.frame	$sp,0,$31		# vars= 0, regs= 0/0, args= 0, gp= 0
	.mask	0x00000000,0
	.fmask	0x00000000,0
	.set	noreorder
	.set	nomacro
	
	addu	$2,$4,$5
	div	$0,$2,$6
	bne	$6,$0,1f
	nop
	break	7
1:
	mflo	$2
	j	$31
	nop

	.set	macro
	.set	reorder
	.end	foo
	.ident	"GCC: (GNU) 3.4.3"

-- 
           Summary: Empty inline assembly cause the generated code to be
                    wrong?
           Product: gcc
           Version: 3.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: yhlin at sdesigns dot com
                CC: gcc-bugs at gcc dot gnu dot org,yhlin at sdesigns dot
                    com
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: mipsel-linux-gcc


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21535

[Bug target/21535] Empty inline assembly cause the generated code to be wrong?

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21535

[Bug target/21535] Empty inline assembly cause the generated code to be wrong?

[rsandifo at gcc dot gnu dot org]

------- Additional Comments From rsandifo at gcc dot gnu dot org  2005-05-16 13:07 -------
You say that p.s doesn't work.  Could you explain why?  The code appears
to be functionally identical to q.s, the only difference being that p.s
allows the assembler to reorder the code and q.s does not.

The effect of an asm is deliberate.  gcc normally tries to put the
whole function inside a ".set noreorder/.set nomacro" block.
But it isn't safe to put asms in such a block because they might
use assembler macros.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21535

[Bug target/21535] Empty inline assembly cause the generated code to be wrong?

[yhlin at sdesigns dot com]

------- Additional Comments From yhlin at sdesigns dot com  2005-05-17 20:44 -------
Reading the output assembly twice, it's true that they are equivalent, it's 
just that the div is run in the branch delay slot of bnez in the firt case.

It seems we need strict prologue/epilogue for __asm__ statements like
.set noreorder
.set nomacro
.set push
...
assembly stuff
...
.set pop

to have exact same code generated?

As a result, the bug is mared as invalid.
Thanks for the help.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21535