other/5115: Inline asm generates incorrect assembler code

[aliberi@acutronic.com]

>Number:         5115
>Category:       other
>Synopsis:       Inline asm generates incorrect assembler code
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 14 06:06:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Armand Liberi
>Release:        2.9-gnupro-98r2
>Organization:
>Environment:
rde3# gcc -v -save-temps -o fpsave fpsave.c
Reading specs from /usr/lib/gcc-lib/i386-coff-lynxos/2.9-gnupro-98r2/specs
gcc version 2.9-gnupro-98r2
 /usr/lib/gcc-lib/i386-coff-lynxos/2.9-gnupro-98r2/cpp -lang-c -v -iprefix /bin/
../lib/gcc-lib/i386-coff-lynxos/2.9-gnupro-98r2/ -undef -D__GNUC__=2 -D__GNUC_MI
NOR__=9 -D__Lynx__ -D__x86__ -D__LITTLE_ENDIAN__ -D__Lynx__ -D__x86__ -D__LITTLE
_ENDIAN__ -Asystem(lynx) -Acpu_arch(x86) -Acpu(i386) -D__i386__ fpsave.c fpsave.
i
GNU CPP version 2.9-gnupro-98r2 (x86, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-lib/i386-coff-lynxos/2.9-gnupro-98r2/../../../../include
 /usr/lib/gcc-lib/i386-coff-lynxos/2.9-gnupro-98r2/../../../../i386-coff-lynxos/
include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i386-coff-lynxos/2.9-gnupro-98r2/cc1 fpsave.i -quiet -dumpbase
 fpsave.c -version -o fpsave.s
GNU C version 2.9-gnupro-98r2 (i386-coff-lynxos) compiled by GNU C version 2.9-g
nupro-98r2.
 /usr/lib/gcc-lib/i386-coff-lynxos/2.9-gnupro-98r2/../../../../i386-coff-lynxos/
bin/as -o fpsave.o fpsave.s
 /usr/lib/gcc-lib/i386-coff-lynxos/2.9-gnupro-98r2/collect2 -o fpsave /lib/init1
.o -L/usr/lib/gcc-lib/i386-coff-lynxos/2.9-gnupro-98r2 -L/usr/lib/gcc-lib/i386-c
off-lynxos/2.9-gnupro-98r2/../../../../i386-coff-lynxos/lib -L/usr/local/lib fps
ave.o -lgcc -lm -lc -lgcc /lib/initn.o
>Description:
Hello,

With the variable declarations:

unsigned int singleInt;
unsigned int lotsOfInts[100]={0};

	asm ("FSTPL %0":"=m" (singleInt));

generates "FSTPL singleInt" as expected, and

	asm ("FSTPL %0":"=m" (lotsOfInts));

generates "FSTPL lotsOfInts" as expected, and

	asm ("FLDL %0"::"m" (singleInt));

generates "FLDL singleInt" as expected, BUT

	asm ("FLDL %0"::"m" (lotsOfInts));

generates "FLDL .LC0" which is NOT expected.

This actually happened using an FSAVE/FRSTOR sequence in a SIGFPE signal handler.  As th eabove illustrates, it was not the instruction but that caused the problem - just that an array address is involved rather than a single variable.  We pay for support from LynuxWorks and they gave me two fixes shown below.  Those also appear to be bugs to me but, like so many other people, I'm a little confused about the constraint rules, etc., and cannot find any clear statement of those rules.  But, I guess that's another problem.

Regards,
Armand

He who asks is a fool for five minutes, but he who does not ask remains a fool forever. - Chinese proverb
Life is just one five minute period after another. - Armand Liberi
>How-To-Repeat:
'gcc -save-temps' the attached file using any version of GCC, I think (I have tried the one described above, the one with RedHat Linux 7.2, and the latest and greatest from CygWin.
>Fix:
Two have been suggested to me by LynuxWorks support:

1.  Change 'asm ("FLDL %0"::"m" (lotsOfInts));'
    to 'asm ("FLDL %0":"=m" (lotsOfInts));'.  I.E., use an output constraint to describe an input (???)

2.  Use 'asm ("FLDL lotsOfInts);'.  I.E., don't use constraints.
>Release-Note:
>Audit-Trail:
>Unformatted: