Re: Compiler issue or something in F95 standard?

Richard E Maine wrote: 
J.F. Cornwall <JCornwall@xxxxxxx> wrote:


Hm.  Edited the program to use len_trim, recompiled it with default F95
parameters so it could use len_trim, and got the same results:



Seems like a compiler bug to me. I did a quick check using NAG f90 to
make sure I didn't miss something. Got the expected results... that is
after I changed all the lnblnk references to len_trim so it would link.

I also had to move the continuation characters over a line. Seemed like
they were in col 7 instead of 6, but that can't be the problem, as it
would have gotten wildly different results. Maybe things got effectively
moved over a column along the way (possibly at my end).

Could have been the cut&paste into the news post editor on my end too. Correct in the source file, tho.

(And the compiler bitched about the nonstandard integer*4, but that's
not related either).

Our code is old enough it dates from a system where the default was integer*2, so there are a great many places it is specified with the *4 notation even today... Plus some coders who always do it that way out of habit.

Mike mentioned one caveat that I want to expand slightly on, though I
don't see how it relates to the current problem. It more relates to
portability of this to f77 compilers.  F77 did not allow zero-length
strings. There were certainly f77 compilers that would refuse to even
compile the '' here. So this code wasn't very portable f77 (in addition
to the integer*4 and lnblnk).

<Ironic_Questioning_ON>What is this "portability" of which you speak?<Ironic_Questioning_OFF> Knowing the history of our code, I am quite certain that portability has never been a significant consideration in the design or coding styles used by any of the authors... And this even though it has been through at least 3 cross-platform ports in its lifetime (CDC Cyber > DG Unix > Sun Solaris).

The compiler we have been using for several years now prior to this update is the Sun Workshop Forte 6.2 F77 compiler. I did find a reference somewhere in the Sun docs about zero-length strings as an extension.

I'm not used to seeing lnblnk as an intrinsic, though I suppose some
compilers might have had such a thing. I'm more used to it as a
user-written function. Because of the "issues" with zero-length strings
in f77, some implementations of lnblnk or equivalents special-cased zero
length. My personal one certainly did. Thus, I wouldn't be much
surprised at "funny" results from lnblnk. Len_trim, however, ought to
work.

I found LNBLNK listed as an intrinsic in the Sun docs for the 6.2 compiler. It does reference LEN_TRIM as the F95 replacement.

I'm suspicious that there is "garbage" in the string for some reason
with your compiler. I might be tempted to look at it more carefully,
perhaps writing out (ichar(label(2)(i:i), i=1,3) to see if something
unprintable snuck in there.


OK, let's try it... First, here is the output from the original test program, as recompiled and executed on one of our other boxes using Forte 6.2:

{jcorn} hqsun4: % comp_test_forte
 Set A
string: meth                                     length:  4
string:                                          length:  0
string:                                          length:  0
 Set B
string:                                          length:  0
string: a                                        length:  1
string:                                          length:  0
{jcorn} hqsun4: %


Then, with the (shortened even more) test program:

{jcorn} hqsun3: % cat comp_test.f90
      PROGRAM MAIN
      IMPLICIT NONE
      INTEGER*4 KNT, I, LEN_TRIM
      PARAMETER (KNT=3)
      CHARACTER LABEL(KNT)*40
      DATA (LABEL(I), I=1, KNT) / 'meth', '', ' '/

      WRITE (*, *) "Set A"
      WRITE (*, 100) LABEL(1), LEN_TRIM (LABEL(1))
      WRITE (*, 100) LABEL(2), LEN_TRIM (LABEL(2))
      WRITE (*, *) (ichar(LABEL(2)(i:i), i=1,3))
      WRITE (*, 100) LABEL(3), LEN_TRIM (LABEL(3))

100   FORMAT ('string: ', A, ' length: ', I3)

      STOP
      END

{jcorn} hqsun3: % f95 -g -o comp_test95 comp_test.f90

WRITE (*, *) (ichar(LABEL(2)(i:i), i=1,3))
^
"comp_test.f90", Line = 11, Column = 46: ERROR: Positional actual arguments in an actual argument list must precede any keywords.

f90comp: 18 SOURCE LINES
f90comp: 1 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI

(disclaimer: It's been a long time since I used ichar and our code doesn't even have any that I am aware of... Please forgive my ignorance on this one...)

Jim
.

Relevant Pages

  • Re: Compiler issue or something in F95 standard?
    ... Seems like a compiler bug to me. ... after I changed all the lnblnk references to len_trim so it would link. ... strings. ... There were certainly f77 compilers that would refuse to even ...
    (comp.lang.fortran)
  • Re: Error writing on unit 22
    ... I used system-dependent code to try to ... It wouldn't shock me if even f77 compilers had it as an extension ... the only "f90 compiler" I ever ran into that didn't ...
    (comp.lang.fortran)