The latest gfortran from www.equation.com (gcc-4.6-20101127-64.exe)
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

On 11/30/2010 02:43 AM, James Van Buskirk wrote:
> 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

"Tobias Burnus" <burnus@net-b.de> wrote in message 
news:4CF53268.3060701@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.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

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

-- 
FX

"FX" <coudert@alussinan.org> wrote in message 
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?

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

On 11/30/2010 10:00 PM, James Van Buskirk wrote:

> 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

On Dec 1, 6:12=A0am, Uno <merrilljen...@q.com> wrote:
> First of all, is this quad precision architecture-independent? =A0I'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=3D10)). The new libquadmath library supports now also on those
architecture a 128bit floating point type ("real(kind=3D16)"), 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

As Tobius says if your using amd or intel hardware then
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=A0pm, Tobias Burnus <bur...@net-b.de> wrote:
> On Dec 1, 6:12=A0am, Uno <merrilljen...@q.com> wrote:
>
> > First of all, is this quad precision architecture-independent? =A0I'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=3D10)). The new libquadmath library supports now also on those
> architecture a 128bit floating point type ("real(kind=3D16)"), 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:
>
> =A0 use iso_fortran_env
> =A0 print *, real_kinds
> =A0 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

On 12/1/2010 6:11 AM, Tobias Burnus 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
>
> 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

Ok.

Do you a have a link for this package that isn't simply the latest build 
from equation?
-- 
Uno

"Tobias Burnus" <burnus@net-b.de> wrote in message 
news:50e0e990-b6ff-4e5e-a3b5-8cdeefeda099@j1g2000vbl.googlegroups.com...

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

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end