From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Modra To: hjl@lucon.org (H.J. Lu) Cc: mikeg@weiden.de, gas2@cygnus.com, egcs@cygnus.com, gcc2@cygnus.com Subject: Re: gcc generates invalid i386 fmulp Date: Tue, 14 Apr 1998 16:45:00 -0000 Message-id: <199804142345.JAA08056@mullet.Levels.UniSA.Edu.Au> References: X-SW-Source: 1998/msg00123.html >hjl@lucon.org (H.J. Lu): > > For anyone who's interested, the gas patches can be found at > > ftp://mullet.levels.unisa.edu.au/private/teabag/gas-980407-alan.diff.gz > > They should apply to binutils-2.9 without problems too. > > > > The gcc problem (found by mikeg@weiden.de (Michael L. Galbraith)), > > when compiling glibc2 is that gcc will generate instructions like > > `fsubp %st(1),%st' > > > > Can you show me a small test case please? It is very tricky. Here are > the ChangeLog entries: > [deleted] Yes, I know it's tricky. Basically, Unixware got their assembler wrong, and we're stuck with an inconsistent syntax. A test case for fmulp is glibc-2.0.6/sysdeps/libm-ieee754/s_nextafterf.c. I put the preprocessed file at ftp://mullet.levels.unisa.edu.au/private/teabag/s_nextafterf.i Mike Galbraith may be able to give you a .i file for the fsubp case; I didn't have the right version of glibc. >From the start of binutils/include/opcodes/i386.h: /* The UnixWare assembler, and possibly other ix86 assemblers, generate floating point instructions with reversed source and destination registers in certain cases. Unfortunately, gcc and possibly many other programs use this reversed syntax, so we're stuck with it. eg. `fsub %st(3),%st' results in st <- st - st(3) as expected, but `fusb %st,%st(3)' results in st(3) <- st - st(3), rather than the expected st(3) <- st(3) - st ! This happens with all the non-commutative arithmetic floating point operations with two register operands, where the source register is %st, and destination register is %st(i). Look for FloatDR below. */ #ifndef UNIXWARE_COMPAT /* Set non-zero for broken, compatible instructions. Set to zero for non-broken opcodes at your peril. gcc generates UnixWare compatible instructions. */ #define UNIXWARE_COMPAT 1 #endif > > It is very different from Intel and very confusing. But changing it > will break many things. I haven't diverged from the UnixWare syntax, even though I'd dearly like to. We just put out a warning for the cases where gcc generates instructions **that won't assemble on UnixWare**. Ian Taylor was kind enough to run a number of test cases through a UnixWare assembler for me. Regards, Alan Modra