Re: gcc generates invalid i386 fmulp

[hjl@lucon.org (H.J. Lu)]

> 
> On Wed, 15 Apr 1998, Alan Modra wrote:
> 
> > >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.
> > 
> 
> I can generate a .i file if H.J wants it, but the fsubp %st(1), %st
> instances are human generated. (3 .S files)
> 

When you write x86 fp asm code, you have to know what you are doing.
It is very very tricky since the x86 fp asm syntax is very very very
different from Intel and it doesn't make much sense sometimes. But
it is the way how AT&T did it years ago. I don't think it can be easily
fixed. You can use "objdump -d" to check opcode against the Intel
reference manual if you are not familar with the A&T x86 asm syntax.


-- 
H.J. Lu (hjl@gnu.org)