Re: "Double Precison" Keywords?

Tobias Burnus <burnus@xxxxxxxx> wrote:
On 01/24/2011 03:16 PM, Daniel Carrera wrote:
Now that you bring it up, what would be the portable way to write
"real(16)"? I'm trying to make the code compile with gfortran, and
gfortran doesn't like "real(16)". At least not on my computer.

gfortran supports since a long time kind=16 when running on hardware
where a 128bit floating-point number is available.

IBM S/370 and successors support 128 bit (extended precision)
in hardware. The VAX architecture includes it, but allows for
software emulation by the OS to support it. VAX compilers, then,
assume that the hardware supports it, whether or not it does.

Other than IBM, is there other hardware currently, or recently,
in production with REAL*16 support?

-- glen
.

Relevant Pages

  • Re: high-precision type
    ... >>> The problem is that most compilers do not support QP. ... >> and compiler writers use what the hardware supplies. ... Or of software emulation in gfortran or g95? ...
    (comp.lang.fortran)
  • Re: "Double Precison" Keywords?
    ... |> gfortran supports since a long time kind=16 when running on hardware ... | in hardware. ... | software emulation by the OS to support it. ...
    (comp.lang.fortran)
  • Missing 2008 GFortran Status Report
    ... discussion for the 2009 GFortran Status Report was ... Fortran compiler and that they are willing to provide both positive ... negative feedback as well as the generally high quality bug reports. ... Support for Fortran 2003 structure constructors and for array ...
    (comp.lang.fortran)
  • Re: Lahey/GNU Fortran
    ... Don't know what Lahey has done, but I can state that gfortran ... does not support the IEEE 754 intrinsic modules. ...  Whatever hits the GCC tree ...
    (comp.lang.fortran)
  • Re: Getting started with libquadmath
    ... As Tobius says if your using amd or intel hardware then ... the native support is for 32, 64 and 80 bit reals. ... with gfortran, and this has not been the case. ...
    (comp.lang.fortran)