Re: gfortran read of hex values

James Van Buskirk wrote:
"Walter Spector" <w6ws_xthisoutx@xxxxxxxxxxxxx> wrote in message news:13m7nvpq3e7hrd7@xxxxxxxxxxxxxxxxxxxxx

That is pretty abusive. Even after changing the square brackets
back to (/ /), only 1 of the 5 compilers I tried would compile it.

Darn, I didn't realize that ifort passes MIL-STD 1753 intrinsics
with mixed KINDs by default. Here is a fix; see if more compilers
like it:

That helps a bit. Yes, ifort compiled and ran both versions. On
the second version:

IRIX f90 (MIPSpro 7.4.4m) does not like the REAL (1, KIND (pi)).
I think, by F95, it has a right to object. (Result of REAL is not
an INTEGER or CHARACTER.) So fixing the initialization
of pi to read the following, works:

integer, parameter :: one = 1.0
integer, parameter :: pi = transfer (ishft (HFu1,16)+HFl1, one)

G95 compiled the (unmodified) second version, but gave a runtime
error when doing the decode in the main program. It doesn't like
using hex conversion into a REAL variable. (Again, I think that
by F95, the RTL has a right to complain.) It works by changing
the main program to:

integer :: ipi1
real :: pi1
equivalence (ipi1, pi1)
...
read(cpi,'(z8)') pi1

Salford loses track of I and whines that it isn't a parameter.
(Simpler cases of using I in an array constructor work OK though.)

And finally gfortran loses track of things when doing the initialization
of ARR1 - which then cascades into errors when initializing HFu1 and HFl1.

Bottom line is that if you fix the two non-Standardisms (by f95), the
success rate goes up to 3 of 5. Salford and gfortran have bugs to fix.

W.
.

Relevant Pages

  • Re: GNU Fortran 95: Opinions?
    ... > and the gfortran people. ... neither should use f95 as their ... So I hope that solves any conflicts with other compilers. ...
    (comp.lang.fortran)
  • ADVANCE=NO and X format? Was Re: Some formatting problems
    ... >Pity the poor compiler-writers trying to make sense of the f95 conflict ... A test program briefer than my previous effort is this 3-liner: ... with X by email with Andy Vaught, I agree that his g95 treatment of it ... for f2003, preferably before compilers appear :-), and yet another ...
    (comp.lang.fortran)
  • Re: intel compiler problem
    ... Allocatable components are part of the allocatable TR (Technical ... They are not part of the base f95. ... A growing number of compilers are supporting the allocatable ... support the TR. ...
    (comp.lang.fortran)
  • Re: matlab to fortran
    ... the differences between f90 and f95 being pretty minor. ... but there are one or two exceptions. ... compilers might happen to implement i0 anyway. ...
    (comp.lang.fortran)
  • Re: gfortran read of hex values
    ... I think, by F95, it has a right to object. ... REAL and even LOGICAL were forbidden in f95 initialization ... expressions is so inclusive that it will break compilers ...
    (comp.lang.fortran)