Re: Syntax check for IMPLICIT statement



Michael Metcalf wrote:

"James Van Buskirk" <not_valid@xxxxxxxxxxx> wrote in message news:wpmdnYLdJ7wLl4jVnZ2dnUVZ_jednZ2d@xxxxxxxxxxxxxx

In attempting to create a digestible version of a program that gives
gfortran an ICE and causes incorrect output for ifort, the critical
factor for both seems to be a line such as:

implicit character(len=*,kind=kind('A')) (Q)

"For a scalar named constant or for a dummy argument ... a len-value may be specified as an asterisk" ("Fortran 95/2003 Explained", Section 7.13).

Even so, it shouldn't ICE.

Still, I don't see, as James seems to believe, that dummy arguments and named constants (also, external functions) can't be done through
IMPLICIT. It might be bad style, but is it illegal?

Does it only fail if used in a MODULE?

-- glen

.



Relevant Pages

  • Syntax check for IMPLICIT statement
    ... gfortran an ICE and causes incorrect output for ifort, ... In the sense that if the LEN is changed to 3 both ifort and gfortran ... end program startest ...
    (comp.lang.fortran)
  • Re: Syntax check for IMPLICIT statement
    ... gfortran an ICE and causes incorrect output for ifort, ...
    (comp.lang.fortran)
  • Re: Specific names for intrinsic functions and optional arguments
    ... nor gfortran to work right. ... ifort 9.something, and SGI IRIX f90. ... if I specify an "optional" BACK dummy arg in the interface ...
    (comp.lang.fortran)
  • Re: Formatted stream I/O
    ... gfortran and ifort agree here, ... ifort writes a single "b". ... Support the Original G95 Project: http://www.g95.org ... Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html ...
    (comp.lang.fortran)
  • Re: compiler problem
    ... i was just trying to see the performance of different compiler ... and there is a problem inthis part of the code: ... while compiling with ifort, its converging after 160k steps, but even ... after waiting for 1000k steps with gfortran, ...
    (comp.lang.fortran)