This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Possible explaination why large_real_kind_form_io_2.f90 is failing on PPC/OSX
- From: dominiq at lps dot ens dot fr (Dominique Dhumieres)
- To: dominiq at lps dot ens dot fr, schnetter at cct dot lsu dot edu
- Cc: fortran at gcc dot gnu dot org
- Date: Sun, 14 Jan 2007 21:04:59 +0100 (CET)
- Subject: Re: Possible explaination why large_real_kind_form_io_2.f90 is failing on PPC/OSX
> By default, gfortran uses something like 6 digits of accuracy in
> write statements. This is not even sufficient to read back real(4)
> numbers in all cases.
Apparently, there are three choices:
(1) output more digits than necessary for a given precision (xlf),
(2) output the minimal number of digits to make the output unabiguous (g95)
(3) output a number of digits shorter by one or two digits than the maximal
length of the minimal unambiguous representations (gfortran, ifort, pgf, ...).
(1) and (3) have advantage of nice alignements if the lines are not too long,
(2) has the advantage to allow easier visual rounding and I think they are
all "standard conforming".
What I questioning is a test of gfortran which can pass its own compilation only
on a subset of the floating point values.
My initial question was only to understand why the test failed on my G5 and if
it was a gfortran(gcc) platform error as the LOGICAL(8) problem of if it was due
to other causes. So now the answer is the latter (bad test case) and I don't want
to make too much noise.
As said on my other mails it seems that there are some bugs lurking behind the
implementation of real(16) in gfortran, but from the answer I cannot understand
if they are due to gfortran/gcc or to Darwin.
Dominique