PR12928 mystery: sigsuspend.s:82: Error: non-constant expression in ".if" statement

[Daniel Kegel]

For perhaps a not very good reason, I'm trying to build
a gcc-3.3.3 / glibc-2.1.3 toolchain for x86.
(glibc-2.1.3 builds fine for me with gcc-2.95.)
and am running into the error

/tmp/ccdGVIRa.s: Assembler messages:
/tmp/ccdGVIRa.s:82: Error: non-constant expression in ".if" statement
/tmp/ccdGVIRa.s:83: Error: non-constant expression in ".if" statement
/tmp/ccdGVIRa.s:86: Error: non-constant expression in ".if" statement
make[2]: *** [/crosstool-0.28-pre4/build/i686-unknown-linux-gnu/gcc-3.3.3-glibc-2.1.3/build-glibc/signal/sigsuspend.o] Error 1


This has been mentioned several times before, with many
different versions of gcc and glibc:

http://mail.gnu.org/archive/html/bug-glibc/2002-11/msg00074.html
http://mail.gnu.org/archive/html/bug-glibc/2002-11/msg00187.html
http://mail.gnu.org/archive/html/bug-glibc/2002-12/msg00073.html
http://sources.redhat.com/ml/libc-alpha/2003-09/msg00131.html
http://www.linuxquestions.org/questions/archive/13/2003/07/1/68551
http://linuxfromscratch.org/pipermail/lfs-book/2003-October/008910.html
http://linuxfromscratch.org/pipermail/lfs-support/2003-July/018504.html

and interestingly
http://gcc.gnu.org/PR12928

Tracing the problem backwards from the line that causes it,
I think the call in sigsuspend.c that has the problem is
   return INLINE_SYSCALL (sigsuspend, 3, 0, 0, set->__val[0]);

INLINE_SYSCALL is defined in libc/sysdeps/unix/sysv/linux/i386/sysdep.h :

#define INLINE_SYSCALL(name, nr, args...) \
   ({                                                                          \
     unsigned int resultvar;                                                   \
     asm volatile (                                                            \
     LOADARGS_##nr                                                             \
     "movl %1, %%eax\n\t"                                                      \
     "int $0x80\n\t"                                                           \
     RESTOREARGS_##nr                                                          \
     : "=a" (resultvar)                                                        \
     : "i" (__NR_##name) ASMFMT_##nr(args) : "memory", "cc");                  \
     if (resultvar >= 0xfffff001)                                              \
       {                                                                       \
         __set_errno (-resultvar);                                             \
         resultvar = 0xffffffff;                                               \
       }                                                                       \
     (int) resultvar; })

#define LOADARGS_0
#define LOADARGS_1 \
     "bpushl .L__X'%k2, %k2\n\t"                                               \
     "bmovl .L__X'%k2, %k2\n\t"
#define LOADARGS_2      LOADARGS_1
#define LOADARGS_3      LOADARGS_1
#define LOADARGS_4      LOADARGS_1
#define LOADARGS_5      LOADARGS_1

#define RESTOREARGS_0
#define RESTOREARGS_1 \
     "bpopl .L__X'%k2, %k2\n\t"
#define RESTOREARGS_2   RESTOREARGS_1
#define RESTOREARGS_3   RESTOREARGS_1
#define RESTOREARGS_4   RESTOREARGS_1
#define RESTOREARGS_5   RESTOREARGS_1

The bpushl etc. macros are defined like this:

         .L__X'%ebx = 1
         .L__X'%ecx = 2
         .L__X'%edx = 2
         .L__X'%eax = 3
         .L__X'%esi = 3
         .L__X'%edi = 3
         .L__X'%ebp = 3
         .L__X'%esp = 3
         .macro bpushl name reg
         .if 1 - \name
         .if 2 - \name
         pushl %ebx
         .else
         xchgl \reg, %ebx
         .endif
         .endif
         .endm

and finally, here are the bad calls:

         bpushl .L__X'$0, $0
         bmovl .L__X'$0, $0
         movl $72, %eax
         int $0x80
         bpopl .L__X'$0, $0

Evidently .L__X'$0 is a malformed reference to one of the
local constants defined above bpushl.

Andrew Pinski asked cryptically in http://gcc.gnu.org/PR12928
   %k2 == $0?
which is exactly where I am stuck.  What the heck does the %k2 in LOADARGS_1 mean?
I guess I'm showing my ignorance of inline assembly here.

And I don't understand at all how the patch in comment #11 of that
bug fixes the problem.  In fact, nothing after comment #5 makes any sense...

Can someone shed some light on this problem?

Thanks,
Dan