problem with endianness of bitfields

[llvmbot]

Bugzilla Link	2724
Resolution	FIXED
Resolved on	Apr 24, 2010 07:06
Version	trunk
OS	Windows XP
Reporter	LLVM Bugzilla Contributor
CC	@bcardosolopes,@jayfoad

Extended Description

Consider this code:

$ cat bf.c
struct {
unsigned char a:4;
unsigned char b:4;
} foo = { 15, 0 };

If I compile it with GCC 4.2.1 built for mips-elf, in both big- and little-endian modes, I get this:

$ objdir-4.2.1-mips/gcc/cc1 -meb -quiet -o - bf.c | grep -A1 ^foo
foo:
.byte 240
$ objdir-4.2.1-mips/gcc/cc1 -mel -quiet -o - bf.c | grep -A1 ^foo
foo:
.byte 15

So in big-endian mode the first field in the structure occupies the most significant bits in the byte; in little-endian mode it occupies the least significant bits.

However, using llvm-gcc (built from svn at revision 55368), I get this:

$ ~/llvm/objdir-gcc-svn-mips/gcc/cc1 -meb -quiet -o - bf.c | grep -A1 ^foo
foo:
.byte 15 # 0xF
$ ~/llvm/objdir-gcc-svn-mips/gcc/cc1 -mel -quiet -o - bf.c | grep -A1 ^foo
foo:
.byte 15 # 0xF

This means that big-endian MIPS code built with llvm-gcc won't interwork with code built with GCC.

[llvmbot]

I think the problem is that various bits of code in llvm-convert.cpp, including ProcessBitFieldInitialization(), use BITS_BIG_ENDIAN to decide how to lay out bitfields. This is wrong; BITS_BIG_ENDIAN is only supposed to affect how the operands of sign_extract and zero_extract RTXs are interpreted, and llvm-gcc has nothing to do with RTL.

I think llvm-convert.cpp should use BYTES_BIG_ENDIAN instead to decide how to lay out bitfields. This is what output_constructor() in varasm.c does, for example.

[bcardosolopes]

Have you tried to generate the llvm-gcc mips cross-compiler for both endians and then compile the code with each one of them? The problem may be in the big/little switch option which isn't passed to the mips backend. I'll check that.

[llvmbot]

The code in llvm-convert is simply bogus if
BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN. But it
is not yet clear to me what BITS_BIG_ENDIAN
means and what should be done in this case.
There is also the question of why MIPS has
different values for them.

[llvmbot]

But it is not yet clear to me what BITS_BIG_ENDIAN means

I believe it only affects the way that RTL patterns for inserting and extracting bitfields are represented. When you're writing a back end, you can choose whether you want the operands of these patterns to be bit numbers starting from the least or most significant end of the word, depending on what matches your CPUs instruction set best.

I don't think BITS_BIG_ENDIAN should affect the operation of GCC in any way until RTL generation time, so I don't think it should affect llvm-gcc in any way.

That's what the documentation seems to say, and I can't see anything in the GCC source that suggests otherwise.

[llvmbot]

test used to determine what mainline gcc does
It looks like the final code produced by gcc does
not depend on how BITS_BIG_ENDIAN is set: I modified
mainline gcc so BITS_BIG_ENDIAN can be specified on
the command line. I then checked that the final
assembler is the same with BITS_BIG_ENDIAN 0 or 1
on the attached testcase (I checked using the
debugger that gcc is really using different code
paths internally). So indeed it looks like llvm-gcc
needs to be changed to use BYTES_BIG_ENDIAN (or,
rather, the endianness info in the LLVM target data).

[llvmbot]

Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080901/066603.html

[llvmbot]

Thanks for the fix!