develooper Front page | perl.perl5.porters | Postings from October 2014

Re: new long doubles option: gcc libquadmath

Thread Previous | Thread Next
From:
Jarkko Hietaniemi
Date:
October 29, 2014 13:35
Subject:
Re: new long doubles option: gcc libquadmath
Message ID:
CAJueppv1FdKyCfzDRv5J-8=aPhSG_9PG8x0y1TayCDQbsarhnw@mail.gmail.com
>>> On my Ubuntu box, Configure fails to find the quadpath library as it is
>>> under "/usr/lib/gcc/x86_64-linux-gnu/4.9" but that directory is not
>>> added to Configure libpath variable.

First of all, thanks for trying out the new option.

Regarding the directory not found I don't know what to do about it.
Configure has certain assumptions that probably shouldn't be tweaked,
or face widespread breakage.

(1) the paths completely private to gcc are *removed* from consideration
(yours is such a path)
(2) in Linux, only non-versioned so-libs are considered.  That is,
libfoo.so.1.0 is not, only libfoo.so.

That is, if your libquadmath is either in a gcc-private directory, or
it's only installed as a versioned so, it won't be found by Configure.
Configure gives a lot of rope
to OS/gcc packages, and unfortunately sometimes that's too much rope.

> After working around that issue with a symbolic link, everything compiles
> properly but now I have noticed that @INC contains paths of the following
> form:
>
>     .../lib/site_perl/5.21.6/x86_64-linux-ld
>
> Shouldn't different paths be used for ld and quadmath?
>
> Are modules compiled with ld and quadmath variants binary compatible?

They most certainly aren't.

Well, let me step back.  A couple of steps.

They most often aren't.  But sometimes they are.

Background: "long double" is a very ill-defined thing.  It doesn't
mean "a particular floating point format".  Not even "a particular
floating point format, with the possible endianness variations".   It
also doesn't mean "whatever the CPU gives" because it may be
completely software-implemented.

What long double really means just "a floating point format, which may
or may not be of more precision/range than 'plain double'" (though
most often it has at least more precision).

Which particular format gets offered by a compiler of course depends strongly
on what the CPU offers.

The most common formats are probably:

(1) the 'x87' FPU format

(2) the IEEE quadruple, can be hardware (alpha) or software (like
quadmath), the "true descendant" of the IEEE double.  Can be of either
endianness, though I'm aware only of little-endian implementations.

(3) the 'double-double' format, all software, in powerpc and mips platforms

The format (1) is vastly most common, because Intel.  I have no good
idea of relative ordering of (2) and (3) but compared to (1) they are
rounding errors (ta-dah!)

The precision (mantissa) and range are respectively

(1) 64+1+15=80

(2) 112+1+15=128

(3) nominally 113 bits of mantissa, but it's complicated... the thing
is a pair of {high, low}, so all the math is all about (a+b)(c+d) =
... kind of dance.

The (2) in fact has 113 bits of mantissa, because of the 'hidden bit'
IEEE trick.

While these formats share some basic IEEE-like semantics, they are
binarily utterly incompatible.  'long double' output in x86 is garbage
in 'double-double' ppc, and vice versa.

Now, to circle back to quadmath and quadmath in Perl.

So no, '-ld' compiled with -Duselongdouble is not compatible with
-Dusequadmath. At least not in x86 platforms.

At the moment the concepts are a bit coupled in Configure and in the
code.  This might have been a mistake, but while I was doing the
integration, "it seemed like a good idea at the moment". I think some
things become simpler if I assumed "usequadmath *also* turned on
"uselongdouble".  This might have been related to the basic
implementation facts

(1) Perl internally has only one floating point type, one cannot even
*think* of, say, doubles and long doubles at the same time
(2) there are in some places two code paths or different macro
definitions that can go either 'normal' or 'long double' ways.

So I didn't feel like adding new alternative code paths, except where
I simply had to (e.g. because libc sprintf-family understands nothing
about quadmath).

But I can revisit this decision, whether coupling 'long double' and
'quadmath' still makes sense.

Regarding the paths, I'm open to suggestions.  -ld-quadmath?  Or just
-quadmath?  In your suggestion please consider the above bedtime
story.

-- 
There is this special biologist word we use for 'stable'. It is
'dead'. -- Jack Cohen

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About