Bug 8916

Summary: [mcore-elf] unsigned char assign gets hosed.
Product: gcc Reporter: jcphillips
Component: targetAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: gcc-bugs, kazu
Priority: P3 Keywords: wrong-code
Version: 3.2   
Target Milestone: 3.3.3   
Host: Target: mcore-elf
Build: Known to work:
Known to fail: Last reconfirmed: 2003-05-26 14:26:40

Description jcphillips 2002-12-12 08:56:02 UTC
The following source fails to generate correct asm:
----------------
extern void ExtFunc(char *c);

void test()
  {
  unsigned char data = 166;
  ExtFunc(&data);
  }
--------------------------
mcore-elf-objdump output is:
--------------------------
test.o:     file format elf32-mcore-big

Disassembly of section .text:

00000000 <test>:
   0:   24f0            subi    r0, 16
   2:   9f20            st      r15, (r0, 8)
   4:   2c07            bmaski  r7, 0
   6:   b700            stb     r7, (r0, 0)
   8:   1202            mov     r2, r0
   a:   7f02            jsri    0x0     // from address pool at 0x14
   c:   8f20            ld      r15, (r0, 8)
   e:   20f0            addi    r0, 16
  10:   00cf            jmp     r15
  12:   0000            bkpt
  14:   0000            bkpt
        ...
--------------------------
The bmaski r7,0 causes the char value to be 0xFF.
When compiled without optimization, result is fine.

Release:
gcc v3.2

Environment:
cygwin.  gcc built for mcore-elf.

How-To-Repeat:
compile with:
 mcore-elf-gcc -c -O2 -mbig-endian -m210 test.c
Comment 1 Dara Hazeghi 2003-05-26 05:54:03 UTC
Hello,

I can confirm that this problem is still present on gcc 3.3 branch and mainline (20030524). 
Thanks,

Dara
Comment 2 Andrew Pinski 2003-05-26 14:26:40 UTC
See Dara's comment.
Comment 3 jcphillips 2003-10-14 20:31:48 UTC
If compiled as little endian, correct code is produced.
Compile with:
     mcore-elf-gcc -c -O2 -m210 test.c
Comment 4 Kazu Hirata 2004-01-02 19:10:56 UTC
With current mainline, different code is generated.  Most notably,
bmaski does not appear any more.  Could you check if the following is
correct?  The following patch fixed many regressions, so this problem
may have been fixed at that time.

http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00044.html

test:
	subi	sp,16
	stw	r15,(sp,8)
	movi	r7,89
	not	r7	// -90 0xffffffa6
	st.b	r7,(sp)
	mov	r2,sp
	jbsr	ExtFunc
	ldw	r15,(sp,8)
	addi	sp,16
	jmp	r15
Comment 5 Kazu Hirata 2004-01-03 16:49:42 UTC
Running the testcase with mcore-elf-run shows it's OK now.
Confirmed on 3.3 branch and mainline.