Irix6 long doubles implemented wrong? (27_io/ostream_inserter_arith)

[Alexandre Oliva]

On Dec 24, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Dec 24, 2002, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:
>> Bootstrap went ok, however there were a couple of regressions in the
>> c-torture testsuite:

> Thanks for catching these.  The fix for va-arg-5.c didn't make it to
> the patch I posted, and the bootstrap obviously didn't catch the lack
> of support for getting long double arguments in varargs lists.  Oops
> :-)

> ieee/20011123-1.c may be a victim of the rounding issue I mentioned
> in my earlier e-mail.  I'll investigate it and post a revised patch.

It was actually a victim of __make_tp not having been declared in the
translation units that called it.  Eek.  So much for testing by
hand...

The libstdc++-v3 failures had to do with __LDBL_DENORM_MIN__ being set
incorrectly.  I ended up changing the real_format structure such that,
instead of assuming the same number of bits is available for the
mantissa of normalized and denormalized numbers and using a bool to
tell whether denorms are available, the number of denorm mantissa bits
is specified by itself, and we test whether it's zero to check whether
denorms are supported.  Then we can tell real.c that only 53 bits are
available in the denorm mantissa of a long double format that has 106
bits of mantissa for normals.  Hmm...  It's actually 52.  /me ponders
whether to adjust the new comment in real.h or all entries, and
figures he can't make his mind up :-)  Suggestions?

> It looks like it's time for me to get expect and dejagnu to build and
> work on IRIX again... :-(

Done.  Wasn't that hard, I just had to find the patches for expect to
build and work on IRIX that I had come up with a while ago.

Anyway, here's the patch for the 3.3 branch.  No failures in
libstdc++-v3 with it (and a number of XPASSes).  Full bootstrap and
test cycle still going, but I've verified by hand that
gcc.c-torture/execute/{va-arg-5.c,ieee/20011123-1.c} now pass, and I
doubt these further tweaks might have actually introduced any
regressions, so...  Ok to install in the 3.3 branch (plus Kaveh's
patch for gcc/config/mips/_tilib.c in mainline), if bootstrap and
regression testing completes?

Oh, I made another change that should speed things up a little bit
too: instead of keeping even more excess precision for the emulation
of IRIX' long double to internally use the same number of bits as IEEE
854 128-bit long doubles, which would probably cause rounding problems
unless I explicitly handled it, I arranged for the emulation library
to already keep 106 bits of mantissa.  This means we never get excess
precision in the final result, even if the would-be-implicit-1 bit of
the least-significant double turns out to be zero and we have to look
for some other less-significant bit for it.  It sounded like a good
idea at first, but I've now realized it may mess up numeric models
that actually depend on exact knowledge of the number of mantissa
bits.  Not that this knowledge can actually be relied upon in case of
denorms...  Or even when the exponent is so small that the
most-significant double is normal but the least-significant one
isn't.  In this case, I believe we should do some rounding, but I was
not sure it actually mattered, so I just left it out.

Another case that I haven't handled is that of numbers that are too
large to represent in a single double, but that could be represented
with the addition of the two doubles, using the maximum exponent on
both.  I figured this is probably not something that is meant to be
done, since the documentation of this format explicitly states that it
doesn't extend the range of exponents, when compared with double.

Also, there's no check that the sign of the least-significant double
is the same as that of the most-significant one, nor is there a check
that the LSD is NaN or +/-Inf.  I'm treating all these cases as
constraint violations in the long double format, that invoke undefined
behavior.  Hope that's ok.

Anyway, enough rambling.  Here's the patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-mips-tfmode-emul-take3.patch
Type: text/x-patch
Size: 51093 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20021225/de304aad/attachment.bin>
-------------- next part --------------

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer