Bug#467486: Investigations about failure

[Andreas Kirschbaum]

gcc-4.2 and gcc-4.3 differ in the representation of char values: gcc-4.2
represents a char as a 32 bit value (bits 0..7 is the char value; bits
8..31 are always set to zero); gcc-4.3 uses only the lower 8 bits,
ignoring bits 8..31.

kaffe defines "typedef unsigned char jboolean;" in
kaffe-1.1.8/libraries/javalib/external/classpath/include/jni_md-x86-linux-gnu.h
but assumes %eax is 0/1 in compiled Java code. This makes compiled Java
code calling into native C code almost always assume "true" for jboolean
return values due to the non-zero "garbage" in bits 8..31.


Compiling the following source demonstrates the issue: compiled with
gcc-4.2, the return value in %eax always is either 0 or 1. Compiled with
gcc-4.3, only %al is set ot 0 or 1; the remaining bits 8..31 of %eax
remain unset.

~ >cat t.c
unsigned char f(int x)
{
        return x == 3;
}

~ >gcc-4.2 -O3 -c -s t.c && objdump -d t.o

t.o:     file format elf32-i386

Disassembly of section .text:

00000000 <f>:
   0:   55                      push   %ebp
   1:   31 c0                   xor    %eax,%eax
   3:   89 e5                   mov    %esp,%ebp
   5:   83 7d 08 03             cmpl   $0x3,0x8(%ebp)
   9:   5d                      pop    %ebp
   a:   0f 94 c0                sete   %al
   d:   c3                      ret

~ >gcc-4.3 -O3 -c -s t.c && objdump -d t.o

t.o:     file format elf32-i386

Disassembly of section .text:

00000000 <f>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   83 7d 08 03             cmpl   $0x3,0x8(%ebp)
   7:   5d                      pop    %ebp
   8:   0f 94 c0                sete   %al
   b:   c3                      ret