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

Re: new long doubles option: gcc libquadmath

Thread Previous | Thread Next
Salvador Fandino
October 29, 2014 15:28
Re: new long doubles option: gcc libquadmath
Message ID:
On 10/29/2014 02:34 PM, Jarkko Hietaniemi wrote:
>>>> 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,
> is not, only
> 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.

Right, but the issue is that perl with the usequadmath option doesn't 
compile out of the box in any Debian derived distribution.

Couldn't libquadmath just be handled as a special case in Configure, 
leaping over the path search code and just adding -lquadmath to the 
linker flags?

>> 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.

Well, I was not asking for that, I just wanted to note that if the perls 
are binary incompatible then they should probably use different search 
paths for the .so files.

I don't know if there is a policy for that kind of things, or even if it 
makes sense anymore.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About