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

[Daniel Kegel <dank at kegel dot com>]

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