Portability Blog (Entries tagged as gcc)

Bad register name "dil" (or "sil")

nospam@example.com (Daniel Fischer) — Fri, 29 May 2009 13:09:23 +0200

This is a piece of code from a project that runs on both the x86 and x86_64 architectures:

 1 static inline int swap_int(int *a, int b) {
 2     asm volatile ("xchg %0, %1" : "+r" (b) , "+m" (*a));
 3     return b;
 4 }

It's fairly easy to see what it does: It swaps two values of type int. This code works perfectly fine on both architectures, provided that you're using a compiler that understands the asm statement, such as gcc. Later, this similar piece of code appears:

 1 static inline int swap_char(char *a, char b) {
 2     asm volatile ("xchg %0, %1" : "+r" (b) , "+m" (*a));
 3     return b;
 4 }

This code still compiles and works just fine. For the most part. But when optimisation is turned on, you may get this error from gcc when building for x86:

Error: bad register name `%dil'

Then you try the same on x86_64 and the error is gone again. No wonder: As opposed to x86, the x86_64 architecture actually has the %dil register.

At first, this appears to be a compiler bug. After all, the compiler is choosing a register that doesn't exist on x86. On closer look, it's a bug in the example code. The issue is that for the b argument, the constraint r is used, indicating that the value should be stored in any general-purpose register. In the first example, this is just fine. All of them will do for 32-bit operations. The second example, on closer examination, actually requires a register whose lower byte is accessible. On x86, there are only four general-purpose registers where this is true: EAX, EBX, ECX and EDX. On x86_64, this is also true for the ESI and EDI registers that are also treated as general-purpose registers on x86.

So what happens is that the compiler correctly chooses the %edi register, which satisfies the r constraint. Later, the xchg instruction is interpreted as referring to two byte-sized values due to the size of the arguments *a and b. Thus, the compiler translates the instruction to its 8-bit form and replaces the register placeholder %0 with the 8-bit form of the %edi register, which is %dil. During assembly, this fails because %dil doesn't actually exist on x86.

If there is a compiler bug, it is only that the error output is misleading. It shouldn't even try to use %dil, it should warn about the real problem.

The real bug is that in the example source, a byte-sized argument was qualified with a constraint that allowed any general-purpose register to be used, where instead, the set should be constrained to registers whose lower byte is available. In gcc, this can be achieved by using the q constraint instead of r.

transparent_union

nospam@example.com (Daniel Fischer) — Sat, 15 Dec 2007 14:32:39 +0100

Let's say you're writing a function that accepts a pointer to an int.

 1 void do_stuff_with_int(int *p) {
 2   /* ... */
 3 }

Later, you notice that the doing stuff operation doesn't depend on signedness at all, and decide that you want to use your function with unsigned int too. Just passing a pointer to an unsigned int will cause a warning. How would you get rid of it in a clean way? Easy, use a union.

 1 typedef union {
 2   int *si;
 3   unsigned int *ui;
 4 } signed_or_unsigned_int_pointer;

Now you have a type that can both contain a pointer to an int, or a pointer to an unsigned int. Wouldn't it be convenient if you could use your shiny new type to indicate that do_stuff_with_int() really can accept both types? That's where gcc's transparent_union attribute comes in. (Some other compilers also support this.)

 1 typedef union {
 2   int *si;
 3   unsigned int *ui;
 4 } signed_or_unsigned_int_pointer
 5 __attribute__((transparent_union));
 6 
 7 void do_stuff_with_int(signed_or_unsigned_int_pointer p) {
 8   /* ... */
 9 }
10 
11 int main() {
12   int a = 0;
13   unsigned int b = 0;
14 
15   do_stuff_with_int(&a);
16   do_stuff_with_int(&b);
17 
18   return 0;
19 }

Now, what's the catch? You can only use transparent_union with unions that contain only types with the same representation. In other words, they need to be the same size. You can't, for example, use it with a 32-bit int and a 64-bit integer, in which case gcc will generate a warning. And lots of errors later on, because you're not passing unions to your function, but any one of their constituent types, which isn't allowed without transparent_union.

And now, the reason why this post is related to portability:

 1 typedef union {
 2   int an_int;
 3   long a_long;
 4 } int_union
 5 __attribute__((transparent_union));

The transparent_union attribute will be ignored on most 64 bit platforms.

Treating int and long as the same type is a beginner's mistake. But what about this code?

 1 typedef union {
 2   int volatile *i;
 3   unsigned int volatile *u;
 4 } int_union
 5 __attribute__((transparent_union));

Should work, shouldn't it?

Turns out it doesn't. That is, it works in most places. It even works on Mac OS X. Unless you build for the 64-bit PowerPC CPU. In that case, the attribute is ignored, even though the two types are still the same size. This only seems to happen on ppc64. On all three other architectures currently supported by Mac OS X, it works.

 1 $ gcc -c t.c -arch ppc
 2 $ gcc -c t.c -arch ppc64
 3 t.c:6: warning: 'transparent_union' attribute ignored
 4 $ gcc -c t.c -arch i386 
 5 $ gcc -c t.c -arch x86_64