mingw Perl: no long doubles?

I

Ilya Zakharevich

Inspecting robot reports on module testing (e.g.,
http://www.nntp.perl.org/group/perl.cpan.testers/2009/11/msg5955376.html
), I see that the version of compiler used for some MSWin32 builds do
not have "honest" long doubles: I see: longdblsize=8.

Can somebody explain the reasoning for such an omission? Or is it a
bug in Configure-stage of Perl build?

Thanks,
Ilya

P.S. Due to a bug in test suite, today it has come to my attension
that similar restrictions exist on s390 and alpha linuxes; but
there it is hardware limitation; while Win32 in question is
ix86...

P.P.S. I know that mingw uses M$'s runtime; maybe it is an ABI
incompatibility between gcc and M$'s compilers? But it should
be trivial to fix by assembler thunks generated by a simple
Perl script...
 
B

Bart Lateur

Ilya said:
Inspecting robot reports on module testing (e.g.,
http://www.nntp.perl.org/group/perl.cpan.testers/2009/11/msg5955376.html
), I see that the version of compiler used for some MSWin32 builds do
not have "honest" long doubles: I see: longdblsize=8.

Can somebody explain the reasoning for such an omission? Or is it a
bug in Configure-stage of Perl build?

Maybe the C compiler is just not capable of real "long doubles"?

Wikipedia says the following about "long double":
http://en.wikipedia.org/wiki/Long_double

In C and related programming languages, long double refers to a
floating point data type that is *often* more precise than
double precision.

On the x86 architecture, most compilers implement long double as
the 80-bit extended precision type supported by that hardware
(sometimes stored as 12 or 16 bytes to maintain data structure
alignment). An exception is Microsoft Visual C++ for x86, which
makes long double a synonym for double.

(emphasis mine)

Microsoft claims that this is not a mistake:
http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx

Long Double

Previous 16-bit versions of Microsoft C/C++ and Microsoft Visual
C++ supported the long double, 80-bit precision data type. In
Win32 programming, however, the long double data type maps to
the double, 64-bit precision data type. The Microsoft run-time
library provides long double versions of the math functions only
for backward compatibility. The long double function prototypes
are identical to the prototypes for their double counterparts,
except that the long double data type replaces the double data
type. The long double versions of these functions should not be
used in new code.

So, in theory, the compiler should support it, but Microsoft recommends
against it.
 
I

Ilya Zakharevich

Wikipedia says the following about "long double":
alignment). An exception is Microsoft Visual C++ for x86, which
makes long double a synonym for double.
Microsoft claims that this is not a mistake:
http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx

Long Double

Previous 16-bit versions of Microsoft C/C++ and Microsoft Visual
C++ supported the long double, 80-bit precision data type. In
Win32 programming, however, the long double data type maps to
the double, 64-bit precision data type. The Microsoft run-time
library provides long double versions of the math functions only
for backward compatibility. The long double function prototypes
are identical to the prototypes for their double counterparts,
except that the long double data type replaces the double data
type. The long double versions of these functions should not be
used in new code.

So, in theory, the compiler should support it, but Microsoft recommends
against it.

Thanks, very enlightening.

I think I can even guess the rationales. Given the crippled alpha
architecture, and the M$'s desire to support Windows-on-alpha, they
want everybody to downgrade to the lowest common denominator...

Or do I miss anything else?

Yours,
Ilya
 
S

sisyphus

Inspecting robot reports on module testing (e.g.,
 http://www.nntp.perl.org/group/perl.cpan.testers/2009/11/msg5955376.html
), I see that the version of compiler used for some MSWin32 builds do
not have "honest" long doubles: I see: longdblsize=8.

Can somebody explain the reasoning for such an omission?  Or is it a
bug in Configure-stage of Perl build?

MinGW certainly has (12 byte) long doubles but I don't know of anyone
having built a mingw perl that has long double support.
To achieve long double support with a mingw-built perl, I would think
it's just a matter of creating an appropriate version of win32/
config.gc ... but then, given that mingw uses the msvcrt.dll runtime,
I envisage there might be some hoops to jump through in order to get
these 'long double' values to print() correctly.

Cheers,
Rob
 
P

Peter J. Holzer

Inspecting robot reports on module testing (e.g.,
http://www.nntp.perl.org/group/perl.cpan.testers/2009/11/msg5955376.html
), I see that the version of compiler used for some MSWin32 builds do
not have "honest" long doubles: I see: longdblsize=8.

Can somebody explain the reasoning for such an omission? Or is it a
bug in Configure-stage of Perl build?

P.S. Due to a bug in test suite, today it has come to my attension
that similar restrictions exist on s390 and alpha linuxes; but
there it is hardware limitation; while Win32 in question is
ix86...

Wrong. The Alpha architecture does have a 128 bit floating point type
(in fact it has two of them: The VAX-compatible H_floating and the alpha
specific (and supposedly IEEE-754 compatible) X_floating type). It's
possible that some compilers don't support it, of course.

hp
 
I

Ilya Zakharevich

Wrong. The Alpha architecture does have a 128 bit floating point type
(in fact it has two of them: The VAX-compatible H_floating and the alpha
specific (and supposedly IEEE-754 compatible) X_floating type). It's
possible that some compilers don't support it, of course.

Interesting: why would gcc be among such compilers? ;-) :-(

http://www.nntp.perl.org/group/perl.cpan.testers/2009/11/msg5974479.html

And this kills my reasoning why M$ would kill long double in its
compilers...

Thanks,
Ilya
 
P

Peter J. Holzer

In <[email protected]>, on
11/13/2009


Does "s390" refer only to IBM's old S/390 line or also to the current
zSeries line? Certainly all current zSeries processors have 64-bit
arithmetic, and I believe that the earliest ones did as well.

Normally a double is 64 bits[1], so a true long double type (i.e., one
which isn't identical to double) has to have more than 64 bits. Typical
sizes are 80 bits (Intel), 96 bits (at least some Motorola processors),
and 128 bits (VAX, Alpha, SPARC(?)).

hp

[1] A standard conforming implementation could get by with 43 bits:
34 bits for the mantissa (DBL_DIG=10), 8 bits for the exponent
(FLT_MAX_10_EXP=37), 1 sign bit.
 
I

Ilya Zakharevich

[Do not get the original yet, so I answer at this place in the thread.]

I never physically touched s390. However, smoke testers DO run tests
on (one? some?) s390 machines (I saw Linux and IIRC NetBSD personalities).

Their perl-config can be seen in individual reports; e.g., follow
almost any Linux red link in
http://matrix.cpantesters.org/?dist=Audio-FindChunks+1.01
(the FreeBSD failure is on alpha). I do not know what generation they
are; but it looks like z:

uname='linux cpan02.zseries.org 2.6.18-92.el5 #1 smp tue apr 29
13:16:58 edt 2008 s390x s390x s390x gnulinux '

(BTW, this failure is still undebugged... This module of mine had
"more than the expented" ;-] share of very embarassing bugs...
Especially given that the XS part takes whooping 5588 bytes. ;-)

Yours,
Ilya
 
I

Ilya Zakharevich

Their perl-config can be seen in individual reports; e.g., follow
almost any Linux red link in
http://matrix.cpantesters.org/?dist=Audio-FindChunks+1.01
(the FreeBSD failure is on alpha). I do not know what generation they
are; but it looks like z:

uname='linux cpan02.zseries.org 2.6.18-92.el5 #1 smp tue apr 29
13:16:58 edt 2008 s390x s390x s390x gnulinux '

Hmm, this particular report

http://www.nntp.perl.org/group/perl.cpan.testers/2009/01/msg3077340.html

is on an architecture WITH long double! So they run tests on quite
different personalities (other tests I saw had longdblsize=8).

Ilya
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,832
Latest member
GlennSmall

Latest Threads

Top