Getting started with libquadmath
James Van Buskirk
has libquadmath, but there are some growing pains. The first is
printing anything:
C:\gfortran\clf\quadtest>type quadtest2.f90
module mykinds
use ISO_FORTRAN_ENV
implicit none
private
public sp, dp, ep, qp
integer, parameter :: sp = REAL_KINDS(1)
integer, parameter :: dp = REAL_KINDS(2)
integer, parameter :: ep = REAL_KINDS(3)
integer, parameter :: qp = REAL_KINDS(4)
end module mykinds
program quadtest
use mykinds
implicit none
real(qp), parameter :: pi = 4*atan(1.0_qp)
write(*,*) sp,dp,ep,qp
write(*,*) pi
end program quadtest
C:\gfortran\clf\quadtest>gfortran quadtest2.f90 -oquadtest2
c:/gcc_equation/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../lib/libquadm
ath.a(hd_init.o): In function `hexdig_init_D2A':
/home/gfortran/gcc-home/workshop/gcc/objdir/x86_64-w64-mingw32/libquadmath/../..
/../gcc-4.6-20101127-mingw/libquadmath/gdtoa/hd_init.c:50: multiple
definition o
f `hexdig_init_D2A'
C:/gcc_equation/x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-hd
_init.o):/home/gfortran/gcc-home/workshop/mingw-w64/objdir/../mingw-w64-v1.0-201
01128/mingw-w64-crt/gdtoa/hd_init.c:44: first defined here
collect2: ld returned 1 exit status
This is triggered by the write(*,*) pi statement. Any suggestions?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Tobias Burnus
> C:\gfortran\clf\quadtest>gfortran quadtest2.f90 -oquadtest2
> c:/gcc_equation/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../lib/libquadm
> ath.a(hd_init.o): In function `hexdig_init_D2A':
> /home/gfortran/gcc-home/workshop/gcc/objdir/x86_64-w64-mingw32/libquadmath/../..
> /../gcc-4.6-20101127-mingw/libquadmath/gdtoa/hd_init.c:50: multiple
> definition o
> f `hexdig_init_D2A'
> C:/gcc_equation/x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-hd
> _init.o):/home/gfortran/gcc-home/workshop/mingw-w64/objdir/../mingw-w64-v1.0-201
> 01128/mingw-w64-crt/gdtoa/hd_init.c:44: first defined here
> collect2: ld returned 1 exit status
The problem is that both MinGW64 (no idea about 32bit MinGW) and
libquadmath use the gdtoa functions.
I have been told that this has been fixed now for MinGW64, but it will
also be fixed for libquadmath. (For compilation, fixing it once is
sufficient.)
Workaround: Link libquadmath dynamically (as DLL) and not statically.
Tobias
James Van Buskirk
news:4CF53268...@net-b.de...
> The problem is that both MinGW64 (no idea about 32bit MinGW) and
> libquadmath use the gdtoa functions.
> I have been told that this has been fixed now for MinGW64, but it will
> also be fixed for libquadmath. (For compilation, fixing it once is
> sufficient.)
> Workaround: Link libquadmath dynamically (as DLL) and not statically.
I tried:
C:\gfortran\clf\quadtest>gfortran quadtest2.f90 -Wl,-Bdynamic -lquadmath
c:/gcc_equation/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../lib/libquadm
ath.a(hd_init.o): In function `hexdig_init_D2A':
/home/gfortran/gcc-home/workshop/gcc/objdir/x86_64-w64-mingw32/libquadmath/../..
/../gcc-4.6-20101127-mingw/libquadmath/gdtoa/hd_init.c:50: multiple
definition o
f `hexdig_init_D2A'
C:/gcc_equation/x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-hd
_init.o):/home/gfortran/gcc-home/workshop/mingw-w64/objdir/../mingw-w64-v1.0-201
01128/mingw-w64-crt/gdtoa/hd_init.c:44: first defined here
collect2: ld returned 1 exit status
It makes sense that such a workaround wouldn't work for me as there
are no *.dll files in my installation. Failed same way for 32-bit
version. MinGW w64 seems to have new builds available today but I
haven't been able to download them yet. Maybe later today.
FX
> are no *.dll files in my installation.
Then download a build *with* shared libraries.
--
FX
James Van Buskirk
news:id3pas$vh4$1...@news.eternal-september.org...
>> It makes sense that such a workaround wouldn't work for me as there
>> are no *.dll files in my installation.
> Then download a build *with* shared libraries.
I finally got the MinGW-w64 binaries:
C:\gfortran\clf\quadtest>gfortran quadtest2.f90 -oquadtest2
ld: cannot find crt2.o: No such file or directory
ld: cannot find crtbegin.o: No such file or directory
ld: cannot find -lgfortran
ld: cannot find -lmingw32
ld: cannot find -lgcc_s
ld: cannot find -lgcc
ld: cannot find -lmoldname
ld: cannot find -lmingwex
ld: cannot find -lmsvcrt
ld: cannot find -luser32
ld: cannot find -lkernel32
ld: cannot find -ladvapi32
ld: cannot find -lshell32
ld: cannot find -lmingw32
ld: cannot find -lgcc_s
ld: cannot find -lgcc
ld: cannot find -lmoldname
ld: cannot find -lmingwex
ld: cannot find -lmsvcrt
ld: cannot find crtend.o: No such file or directory
C:\gfortran\clf\quadtest>gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-w64-mingw32
Configured with:
../../../build/gcc/src/configure --target=x86_64-w64-mingw32 --
prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-sysroot=/c
/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --enable-languages=all,obj
-c++ --enable-fully-dynamic-string --disable-multilib
Thread model: win32
gcc version 4.5.2 20101129 (prerelease) (GCC)
-------------------------------------------------------------------
C:\gfortran\clf\quadtest>gfortran quadtest2.f90 -oquadtest2
f951: error: CPU you selected does not support x86-64 instruction set
C:\gfortran\clf\quadtest>gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
Target: i686-w64-mingw32
Configured with:
../../../build/gcc/src/configure --target=i686-w64-mingw32 --pr
efix=/c/bb/vista64-mingw32/mingw-x86-x86/build/build/root --with-sysroot=/c/bb/v
ista64-mingw32/mingw-x86-x86/build/build/root --enable-languages=all,obj-c++
--e
nable-fully-dynamic-string --disable-multilib
Thread model: win32
gcc version 4.5.2 20101129 (prerelease) (GCC)
Ideas for further progress?
Uno
> Ideas for further progress?
>
I'm reading usenet again for the first time in a while, so I'm
guaranteed to be johnny come lately.
First of all, is this quad precision architecture-independent? I've
made the mistake before of thinking that I could get qp on my machine
with gfortran, and this has not been the case.
Secondly, you left the _qp tag off the 4.0 constant, which is not the
most profound of insights, but a note is a note.
Cheers,
--
Uno
Tobias Burnus
> First of all, is this quad precision architecture-independent? I've
> made the mistake before of thinking that I could get qp on my machine
> with gfortran, and this has not been the case.
No, it is architecture dependent. On x86, x86-64, ia64 the hardware
only supports up to 80bits floating-point numbers (gfortran, g95:
real(kind=10)). The new libquadmath library supports now also on those
architecture a 128bit floating point type ("real(kind=16)"), which
does some parts of the calculation in software. Cf.
http://gcc.gnu.org/gcc-4.6/changes.html
Hence, depending on the architecture (and ABI of the operating
system), you have with gfortran the following real kind numbers/byte
sizes: 4 and 8; 4, 8 and 16; 4, 8, 10 and 16; and 4, 8 and 10. That
roughly matches in C: float, double, long double and __float128, where
only some systems have __float128 and some of the types might have the
same size. The libquadmath library can be used (also from C/C++) when
there is a __float128 type available.
To see the available kind numbers, you can use:
use iso_fortran_env
print *, real_kinds
end
(Which assumes you have (a not too old) gfortran 4.6 or another
compiler supporting this Fortran 2008 feature.)
Note 1: Some compilers have a "quad type" ("real(16)") which is in
reality a 80bit and not 128bit type. You need to check your compiler
documentation.
Note 2: Depending on the arithmetic operation, the quad-precision
operations on x86, x86-64, ia64 can be up to ~200 times slower than
for double precision - others might be just <2 times slower.
Note 3: Currently, GCC's libquadmath does not yet support all Fortran
2008/C99 math functions; for instance the complex inverse
trigonometric/hyperbolic functions are missing or the quad version of
C99's fmal.
Note 4: There are still some integration issues with libquadmath (see,
e.g., the gdtoa linkage error in this thread - but there are more).
The issues can be expected to get fixed over the next weeks/months.
Tobias
Ian
the native support is for 32, 64 and 80 bit reals.
the rest is done in software.
the polyhedron site
http://www.polyhedron.com/pb05-win32-language0html
has details of which compilers support which precisions,
though the data for 95 on linux seems to be out of date.
see below.
running g95 we get
ian@linux-g8j0:~/document/fortran/newbook/examples/ch08> g95
ch0806.f90 ian@linux-g8j0:~/document/fortran/newbook/examples/ch08> ./
a.out
Integer values
Kind Huge
8 9223372036854775807
1 127
2 32767
4 2147483647
8 9223372036854775807
Real values
Kind Precision Tiny
Huge
Epsilon
4 6 1.1754944E-38 3.4028235E
+38
1.1920929E-7
4 6 1.1754944E-38 3.4028235E
+38
1.1920929E-7
8 15 2.2250738585072014E-308 1.7976931348623157E+308
2.220446049250313E-16
10 18 3.3621031431120935063E-4932
1.189731495357231765E+4932 1.084202172485504434E-19
16 33 3.3621031431120935062626778173217526E-4932
1.189731495357231765085759326628007E+4932
1.9259299443872358530559779425849273E-34
On Dec 1, 1:11 pm, Tobias Burnus <bur...@net-b.de> wrote:
> On Dec 1, 6:12 am, Uno <merrilljen...@q.com> wrote:
>
> > First of all, is this quad precision architecture-independent? I've
> > made the mistake before of thinking that I could get qp on my machine
> > with gfortran, and this has not been the case.
>
> No, it is architecture dependent. On x86, x86-64, ia64 the hardware
> only supports up to 80bits floating-point numbers (gfortran, g95:
> real(kind=10)). The new libquadmath library supports now also on those
> architecture a 128bit floating point type ("real(kind=16)"), which
> does some parts of the calculation in software. Cf.http://gcc.gnu.org/gcc-4.6/changes.html
Uno
Ok.
Do you a have a link for this package that isn't simply the latest build
from equation?
--
Uno
James Van Buskirk
> Note 4: There are still some integration issues with libquadmath (see,
> e.g., the gdtoa linkage error in this thread - but there are more).
> The issues can be expected to get fixed over the next weeks/months.
The latest versions from http://www.equation.com:
C:\gfortran\clf\quadtest>gfortran quadtest2.f90 -oquadtest2
C:\gfortran\clf\quadtest>quadtest2
4 8 10 16
3.1415926535897932384626433832795028
C:\gfortran\clf\quadtest>gfortran -v
Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/gcc_equation/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/
lto-wrapper.exe
Target: x86_64-w64-mingw32
Thread model: win32
gcc version 4.6.0 20101204 (experimental) (GCC)
-------------------------------------------------------------
C:\gfortran\clf\quadtest>gfortran quadtest2.f90 -oquadtest2
C:\gfortran\clf\quadtest>quadtest2
4 8 10 16
3.1415926535897932384626433832795028
C:\gfortran\clf\quadtest>gfortran -v
Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/gcc_equation32/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/l
to-wrapper.exe
Target: i686-pc-mingw32
Thread model: win32
gcc version 4.6.0 20101204 (experimental) (GCC)