Problem with extended asm clobber

[Eric Rudd]

In gcc v2.95, a change was made in the way that gcc handles clobbered
registers in extended asm statements.  It is discussed in the gcc FAQ:

   http://www.gnu.org/software/gcc/faq.html#asmclobber

Unfortunately, the change broke a lot of my existing code.  After
grumbling about the docs for earlier versions that didn't warn me about
this problem, I resolved to revise my code to conform to what the
current docs seem to be specifying.

Some of the my subroutines are much more complicated than was apparently
anticipated by the gcc designers, because I have run into a problem that
I haven't been able to work around.  (I am assembling for Intel x86
processors.)

Here is an example of the difficulty.  To simplify the example, I have
gutted the code inside the asm, but the compiler's misbehavior is
identical with the useful routine.  Under the pre-2.95 versions, I was
able to write

   asm volatile(
     "nop"
   :
   : "c"  (n),
     "t"  (t),
     "S"  (a),
     "a"  (inca),
     "D"  (b),
     "b"  (incb)
   : "%ecx", "%esi", "%eax", "%edi", "%ebx", "memory"
   );

where five of the six input arguments were destroyed in the course of
the computations (omitted here).  Under 2.95, I am forced to write

   int d0, d1, d2, d3, d4;       /* Dummy variables, discarded */
   asm volatile(
     "nop"
   : "=c" (d0),
     "=S" (d1),
     "=a" (d2),
     "=D" (d3),
     "=b" (d4)
   : "0"  (n),
     "t"  (t),
     "1"  (a),
     "2"  (inca),
     "3"  (b),
     "4"  (incb)
   : "memory"
   );
}

but beyond the manifest awkwardness of the dummy variables (and the
re-numbering of existing arguments that it necessitates), there arises a
new problem: where there previously had been six operands, there are now
11, and gcc now complains that it can't handle more than 10 operands to
an extended asm.

Here is the output of the compiler with the -v option:

Reading specs from c:/dj203/lib/gcc-lib/djgpp/2.951/specs
gcc version 2.95.1 19990816 (release)
 c:/dj203/lib/gcc-lib/djgpp/2.951/cpp.exe -lang-c -v -D__GNUC__=2
-D__GNUC_MINOR__=95 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__unix__
-D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__unix -D__i386
-D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(msdos)
-Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i386) -Di386 -D__i386
-D__i386__ -D__tune_pentium__ -imacros
c:/dj203/lib/../include/sys/version.h -remap trouble.c
c:/brief/tmp\ccvy8J3v.i
GNU CPP version 2.95.1 19990816 (release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 c:/c/h
 c:/dj203/include
 c:/dj203/lib/gcc-lib/djgpp/2.951/include
 c:/dj203/include
End of search list.
The following default directories have been omitted from the search
path:
 $DJDIR/lang/cxx
 $DJDIR/lib/gcc-lib/djgpp/2.951/../../../../djgpp/include
End of omitted list.
 c:/dj203/lib/gcc-lib/djgpp/2.951/cc1.exe c:/brief/tmp\ccvy8J3v.i -quiet
-dumpbase trouble.c -version -o c:/brief/tmp\ccGLpBMU.s
GNU C version 2.95.1 19990816 (release) (djgpp) compiled by GNU C
version 2.95.1 19990816 (release).
trouble.c: In function `trouble':
trouble.c:31: more than 10 operands in `asm'

Thus, the extended asm feature has become virtually useless to me in
2.95, so I'm stuck with an earlier version of gcc.  Is there any
solution to this exasperating problem?

-Eric Rudd
rudd@cyberoptics.com