This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]