This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: GAS problems
- To: Horst von Brand <vonbrand at sleipnir dot valparaiso dot cl>
- Subject: Re: GAS problems
- From: Alan Modra <alan at SPRI dot Levels dot UniSA dot Edu dot Au>
- Date: Tue, 19 Oct 1999 14:01:01 +0930 (CST)
- cc: binutils at sourceware dot cygnus dot com
On Mon, 18 Oct 1999, Horst von Brand wrote:
> Alan Modra <alan@SPRI.Levels.UniSA.Edu.Au> said:
> > On Sun, 17 Oct 1999, Horst von Brand wrote:
> > > The lcc C compiler on ia32 generates "fxxxp %st(1),%st" instructions to
> > > handle floating point operations. This is handled wrong by H.J.Lu's
> > > binutils-2.9.5.0.16. Note that now it translates "fsubp %st(1),%st" into
> > > "fsubp %st,%st(1)", which does something very different. Also, the
> > > instructions are legal AFAIK (they used to work before), so either no
> > > warning is needed or you could use f.ex. "fsubrp %st,%st(1)" if there is a
> > > penalty of some sort. In any case, I would prefer you left them alone.
>
> > These floating point operations are a real pain, but in this case lcc is
> > doing something wrong. There is no such x86 instruction. What should
> > "fsubp %st(1),%st" do? I'd imagine it should do st <- st - st(1), then
> > pop off the result, which is a bit silly.
>
> No, it would do st(0) - st(1), pop both and push the result. Note that this
> is _not_ st(1) - st(0).
Well, your imagination is better than mine :-) Regardless of what we
think the instruction should do, there is no such x86 instruction. Check
the intel manuals.
> > Note that older binutils
> > silently did the same translation we now do (and older gcc emitted this
> > wrong instruction too)
>
> They did not: lcc used to work.
Can I have a testcase, with lcc's generated asm file?
> > FYI, here's a comment I added to binutils/include/opcode/i386.h, just to
> > make you aware of a horrible kludge.
> >
> > /* The UnixWare assembler, and probably other AT&T derived ix86 Unix
> > 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
> > `fsub %st,%st(3)' results in st(3) <- st - st(3), rather than
> > the expected st(3) <- st(3) - st !
>
> This is _not_ expected behaviour! It gets the operation backwards. If you
> do that, use fsubr in the "translation".
Are you saying that `fsub %st,%st(3)' should result in st(3) <- st-st(3) ?
That's different to every other subtract instruction. Consider
subl `%eax,%ebx' and `subl %ebx,%eax'. In general `op l,r' => r <- r op l
at least in AT&T syntax.
Ian Taylor and I checked gas behaviour vs Unixware fairly exhaustively
back in Jun 1998, when this was all tidied up.
> > 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
> >
> > I would love to get rid of this stupidity, but that needs a
> > synchronised update of both gcc and binutils.
>
> Strange. gcc and lcc used to work for me. Any specific testcase that shows
> gcc generating garbage?
Attached. Use a fairly old gcc (2.7.2 ?) to show the problem.
/*
* inspired by glibc-2.0.6/sysdeps/libm-ieee754/s_nextafterf.c
*
* gcc -O2 -S -DOP=+ gives faddp %st(1),%st
* gcc -O2 -S -DOP=* gives fmulp %st(1),%st
* gcc -O2 -S -DOP=- gives fsubrp %st(1),%st
* gcc -O2 -S -DOP=/ gives fdivrp %st(1),%st
*/
#ifndef OP
#define OP *
#endif
typedef int int32_t __attribute__ ((__mode__ ( __SI__ ))) ;
typedef unsigned int u_int32_t __attribute__ ((__mode__ ( __SI__ ))) ;
typedef union
{
float value;
u_int32_t word;
} ieee_float_shape_type;
float __nextafterf(float x, float y)
{
int32_t hx,hy,ix,iy;
{
ieee_float_shape_type gf_u;
gf_u.value = x;
hx = gf_u.word;
}
{
ieee_float_shape_type gf_u;
gf_u.value = y;
hy = gf_u.word;
}
ix = hx&0x7fffffff;
iy = hy&0x7fffffff;
if ( ix > 0x7f800000 || iy > 0x7f800000 )
return x+y;
if (x == y) return x;
if (ix == 0)
{
{
ieee_float_shape_type sf_u;
sf_u.word = (hy&0x80000000) | 1;
x = sf_u.value;
}
y = x*x;
if (y == x) return y; else return x;
}
if (hx >= 0)
{
if (hx > hy)
hx -= 1;
else
hx += 1;
}
else
{
if (hy >= 0 || hx > hy)
hx -= 1;
else
hx += 1;
}
hy = hx & 0x7f800000;
if (hy >= 0x7f800000)
return x+x;
if (hy < 0x00800000)
{
y = x OP x;
if (y != x)
{
ieee_float_shape_type sf_u;
sf_u.word = hx;
y = sf_u.value;
return y;
}
}
{
ieee_float_shape_type sf_u;
sf_u.word = hx;
x = sf_u.value;
}
return x;
}