Home > Archive > Fortran > January 2006 > Compiler issue or something in F95 standard?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Compiler issue or something in F95 standard?
|
|
| J.F. Cornwall 2006-01-23, 7:04 pm |
| Hi all. We have just taken the long-overdue plunge and converted one of
our development systems from the Sun F77 compiler (Forte 6.2) to the
current SunStudio 11 suite. One of our team has found something that
may be a conversion issue for his part of the code. We're not sure if
it is a compiler-specific issue or something that's part of the F95
standard. Test program that illustrates the question is below:
{jcorn} hqsun3: % cat comp_test.f
PROGRAM MAIN
IMPLICIT NONE
INTEGER*4 KNT, LNBLNK, I
PARAMETER (KNT=3)
CHARACTER LABEL(KNT)*40
CHARACTER LLB(3)*40
INTEGER*4 BB(KNT)
DATA (LABEL(I), I=1, KNT)/
+ 'meth',
+ '',
+ ' '/
DATA LLB/'', 'a', ' '/
!
WRITE (*, *) "Set A"
WRITE (*, 100) LABEL(1), LNBLNK (LABEL(1))
WRITE (*, 100) LABEL(2), LNBLNK (LABEL(2))
WRITE (*, 100) LABEL(3), LNBLNK (LABEL(3))
!
WRITE (*, *) "Set B"
WRITE (*, 100) LLB(1), LNBLNK (LLB(1))
WRITE (*, 100) LLB(2), LNBLNK (LLB(2))
WRITE (*, 100) LLB(3), LNBLNK (LLB(3))
!
100 FORMAT ('string: ', A, ' length: ', I2)
STOP
END
{jcorn} hqsun3: % f77 -V
NOTICE: Invoking /opt/SUNWspro/bin/f90 -f77 -ftrap=%none -V
f90: Sun Fortran 95 8.2 2005/10/13
Usage: f90 [ options ] files. Use 'f90 -flags' for details
{jcorn} hqsun3: % f77 -o comp_test comp_test.f
NOTICE: Invoking /opt/SUNWspro/bin/f90 -f77 -ftrap=%none -o comp_test
comp_test.f
comp_test.f:
MAIN main:
{jcorn} hqsun3: % comp_test
Set A
string: meth length: 4
string: length: 40
string: length: 0
Set B
string: length: 0
string: a length: 1
string: length: 0
{jcorn} hqsun3: %
Jim (another one, not me) was expecting a length of zero for hte second
item in Set A. Instead he got 40... This is the one initialized with
the '' expression inside the implied-do loop in the DATA statement.
In Set B, the same use of '' in a plain old DATA statement without the
loop results in a zero length.
Is this behaviour part of the standard or something compiler-specific?
Jim Cornwall
| |
| Michael Metcalf 2006-01-23, 7:04 pm |
|
"J.F. Cornwall" <JCornwall@cox.net> wrote in message
news:43D4E270.6030901@cox.net...
>
> Jim (another one, not me) was expecting a length of zero for hte second
> item in Set A. Instead he got 40... This is the one initialized with the
> '' expression inside the implied-do loop in the DATA statement.
>
> In Set B, the same use of '' in a plain old DATA statement without the
> loop results in a zero length.
>
I, too, would expect 0. Note that '' is a feature that didn't exist in F77
and LNBLNK is a non-standard intrinsic. Try using len_trim.
Regards,
Mike Metcalf
| |
| J.F. Cornwall 2006-01-23, 7:04 pm |
| Michael Metcalf wrote:
> "J.F. Cornwall" <JCornwall@cox.net> wrote in message
> news:43D4E270.6030901@cox.net...
>
>
> I, too, would expect 0. Note that '' is a feature that didn't exist in F77
> and LNBLNK is a non-standard intrinsic. Try using len_trim.
>
> Regards,
>
> Mike Metcalf
>
>
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:
{jcorn} hqsun3: % cat comp_test.f
PROGRAM MAIN
IMPLICIT NONE
integer len_trim
INTEGER*4 KNT, LNBLNK, I
PARAMETER (KNT=3)
CHARACTER LABEL(KNT)*40
CHARACTER LLB(3)*40
INTEGER*4 BB(KNT)
DATA (LABEL(I), I=1, KNT)/
+ 'meth',
+ '',
+ ' '/
DATA LLB/'', 'a', ' '/
!
WRITE (*, *) "Set A"
WRITE (*, 100) LABEL(1), LNBLNK (LABEL(1))
WRITE (*, 100) LABEL(2), LEN_TRIM (LABEL(2))
WRITE (*, 100) LABEL(2), LNBLNK (LABEL(2))
WRITE (*, 100) LABEL(3), LNBLNK (LABEL(3))
!
WRITE (*, *) "Set B"
WRITE (*, 100) LLB(1), LNBLNK (LLB(1))
WRITE (*, 100) LLB(2), LNBLNK (LLB(2))
WRITE (*, 100) LLB(3), LNBLNK (LLB(3))
!
100 FORMAT ('string: ', A, ' length: ', I2)
STOP
END
{jcorn} hqsun3: % f95 -o comp_test95 comp_test.f
{jcorn} hqsun3: % comp_test95
Set A
string: meth length: 4
string: length: 40 <<<<<< LEN_TRIM
string: length: 40 <<<<<< LNBLNK
string: length: 0
Set B
string: length: 0
string: a length: 1
string: length: 0
| |
| Michael Metcalf 2006-01-23, 7:04 pm |
|
"J.F. Cornwall" <JCornwall@cox.net> wrote in message
news:ItJx3C.5y8@igsrsparc2.er.usgs.gov...
> Michael Metcalf 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:
>
Then it looks like a compiler bug. CVF and g95 both give 0.
Regards,
Mike Metcalf
| |
| Richard E Maine 2006-01-23, 7:04 pm |
| J.F. Cornwall <JCornwall@cox.net> 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).
(And the compiler bitched about the nonstandard integer*4, but that's
not related either).
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).
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'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.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Herman D. Knoble 2006-01-23, 7:04 pm |
| I believe that your initial question about compiler problem has
been solved by other posters (like Mike Metcalf).
Another issue with your program that seems to generate compiler errors for
some compilers is the use of Fortran 90 comments BUT Fortran 77 continuation
notation (+'s in column 6). It helps in this case to name the source
file with an .F extension rather than .F90.
Skip Knoble
On Mon, 23 Jan 2006 14:04:32 GMT, "J.F. Cornwall" <JCornwall@cox.net> wrote:
-|Hi all. We have just taken the long-overdue plunge and converted one of
-|our development systems from the Sun F77 compiler (Forte 6.2) to the
-|current SunStudio 11 suite. One of our team has found something that
-|may be a conversion issue for his part of the code. We're not sure if
-|it is a compiler-specific issue or something that's part of the F95
-|standard. Test program that illustrates the question is below:
-|
-|{jcorn} hqsun3: % cat comp_test.f
-| PROGRAM MAIN
-| IMPLICIT NONE
-| INTEGER*4 KNT, LNBLNK, I
-| PARAMETER (KNT=3)
-| CHARACTER LABEL(KNT)*40
-| CHARACTER LLB(3)*40
-| INTEGER*4 BB(KNT)
-| DATA (LABEL(I), I=1, KNT)/
-| + 'meth',
-| + '',
-| + ' '/
-| DATA LLB/'', 'a', ' '/
-|!
-| WRITE (*, *) "Set A"
-| WRITE (*, 100) LABEL(1), LNBLNK (LABEL(1))
-| WRITE (*, 100) LABEL(2), LNBLNK (LABEL(2))
-| WRITE (*, 100) LABEL(3), LNBLNK (LABEL(3))
-|!
-| WRITE (*, *) "Set B"
-| WRITE (*, 100) LLB(1), LNBLNK (LLB(1))
-| WRITE (*, 100) LLB(2), LNBLNK (LLB(2))
-| WRITE (*, 100) LLB(3), LNBLNK (LLB(3))
-|!
-| 100 FORMAT ('string: ', A, ' length: ', I2)
-|
-| STOP
-| END
-|
-|{jcorn} hqsun3: % f77 -V
-|NOTICE: Invoking /opt/SUNWspro/bin/f90 -f77 -ftrap=%none -V
-|f90: Sun Fortran 95 8.2 2005/10/13
-|Usage: f90 [ options ] files. Use 'f90 -flags' for details
-|{jcorn} hqsun3: % f77 -o comp_test comp_test.f
-|NOTICE: Invoking /opt/SUNWspro/bin/f90 -f77 -ftrap=%none -o comp_test
-|comp_test.f
-|comp_test.f:
-| MAIN main:
-|{jcorn} hqsun3: % comp_test
-| Set A
-|string: meth length: 4
-|string: length: 40
-|string: length: 0
-| Set B
-|string: length: 0
-|string: a length: 1
-|string: length: 0
-|{jcorn} hqsun3: %
-|
-|Jim (another one, not me) was expecting a length of zero for hte second
-|item in Set A. Instead he got 40... This is the one initialized with
-|the '' expression inside the implied-do loop in the DATA statement.
-|
-|In Set B, the same use of '' in a plain old DATA statement without the
-|loop results in a zero length.
-|
-|Is this behaviour part of the standard or something compiler-specific?
-|
-|Jim Cornwall
| |
| Richard E Maine 2006-01-23, 7:04 pm |
| Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu> wrote:
> I believe that your initial question about compiler problem has
> been solved by other posters (like Mike Metcalf).
>
> Another issue with your program that seems to generate compiler errors for
> some compilers is the use of Fortran 90 comments BUT Fortran 77 continuation
> notation (+'s in column 6). It helps in this case to name the source
> file with an .F extension rather than .F90.
Please note that fixed source form is not just "Fortran 77" form. It is
also valid f90. It isn't even obsolescent in f90, though it is in f95
and f2003. But obsolescent features are still a valid part of the
language. In particular, the combination of the "!" trailing comment
indicator with fixed source form is completely standard f90. If you have
an f90 compiler that complains about this, I'd like to know.
Now if your compiler (f95 or later) complains that fixed source form is
obsolescent, that's fine (and even required as a capability). If you get
compiler complaints because you have incorrectly told the compiler that
thsi is free source form code (perhaps implicitly and inadvertantly by
choice of file name), then that is also expected.
If you are using an f77 compiler, you might get complaints about the "!"
comments (along with several other things in the code that are not
standard f77, as pointed out elsethread).
But you should not get any complaint at all from any compiler related to
mixing fixed source form and "!" comments. You might get complaints
about one feature or the other, as noted above, but not about mixing
them.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Herman D. Knoble 2006-01-23, 7:04 pm |
| Richard: If the file extension is .F all compiler that I know of will
compile the code. If the file extension is .F90, I know of no compiler
which will accept the F77 continuation. This includes g95.
Thanks.
Skip
On Mon, 23 Jan 2006 09:35:42 -0800, nospam@see.signature (Richard E Maine) wrote:
-|Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu> wrote:
-|
-|> I believe that your initial question about compiler problem has
-|> been solved by other posters (like Mike Metcalf).
-|>
-|> Another issue with your program that seems to generate compiler errors for
-|> some compilers is the use of Fortran 90 comments BUT Fortran 77 continuation
-|> notation (+'s in column 6). It helps in this case to name the source
-|> file with an .F extension rather than .F90.
-|
-|Please note that fixed source form is not just "Fortran 77" form. It is
-|also valid f90. It isn't even obsolescent in f90, though it is in f95
-|and f2003. But obsolescent features are still a valid part of the
-|language. In particular, the combination of the "!" trailing comment
-|indicator with fixed source form is completely standard f90. If you have
-|an f90 compiler that complains about this, I'd like to know.
-|
-|Now if your compiler (f95 or later) complains that fixed source form is
-|obsolescent, that's fine (and even required as a capability). If you get
-|compiler complaints because you have incorrectly told the compiler that
-|thsi is free source form code (perhaps implicitly and inadvertantly by
-|choice of file name), then that is also expected.
-|
-|If you are using an f77 compiler, you might get complaints about the "!"
-|comments (along with several other things in the code that are not
-|standard f77, as pointed out elsethread).
-|
-|But you should not get any complaint at all from any compiler related to
-|mixing fixed source form and "!" comments. You might get complaints
-|about one feature or the other, as noted above, but not about mixing
-|them.
| |
| Herman D. Knoble 2006-01-23, 7:04 pm |
| Well, I goofed again. If a compiler is explicitly told that a file with
extension, .F90 is fixed (via a parm like Lahey option -fix, for example
all compilers that I know about will compile this code. So you are correct,
Richard.
Skip
On Mon, 23 Jan 2006 13:04:37 -0500, Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu>
wrote:
-|Richard: If the file extension is .F all compiler that I know of will
-|compile the code. If the file extension is .F90, I know of no compiler
-|which will accept the F77 continuation. This includes g95.
-|
-|Thanks.
-|Skip
-|
-|On Mon, 23 Jan 2006 09:35:42 -0800, nospam@see.signature (Richard E Maine) wrote:
-|
-|-|Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu> wrote:
-|-|
-|-|> I believe that your initial question about compiler problem has
-|-|> been solved by other posters (like Mike Metcalf).
-|-|>
-|-|> Another issue with your program that seems to generate compiler errors for
-|-|> some compilers is the use of Fortran 90 comments BUT Fortran 77 continuation
-|-|> notation (+'s in column 6). It helps in this case to name the source
-|-|> file with an .F extension rather than .F90.
-|-|
-|-|Please note that fixed source form is not just "Fortran 77" form. It is
-|-|also valid f90. It isn't even obsolescent in f90, though it is in f95
-|-|and f2003. But obsolescent features are still a valid part of the
-|-|language. In particular, the combination of the "!" trailing comment
-|-|indicator with fixed source form is completely standard f90. If you have
-|-|an f90 compiler that complains about this, I'd like to know.
-|-|
-|-|Now if your compiler (f95 or later) complains that fixed source form is
-|-|obsolescent, that's fine (and even required as a capability). If you get
-|-|compiler complaints because you have incorrectly told the compiler that
-|-|thsi is free source form code (perhaps implicitly and inadvertantly by
-|-|choice of file name), then that is also expected.
-|-|
-|-|If you are using an f77 compiler, you might get complaints about the "!"
-|-|comments (along with several other things in the code that are not
-|-|standard f77, as pointed out elsethread).
-|-|
-|-|But you should not get any complaint at all from any compiler related to
-|-|mixing fixed source form and "!" comments. You might get complaints
-|-|about one feature or the other, as noted above, but not about mixing
-|-|them.
| |
| J.F. Cornwall 2006-01-23, 7:04 pm |
| Herman D. Knoble wrote:
> I believe that your initial question about compiler problem has
> been solved by other posters (like Mike Metcalf).
>
> Another issue with your program that seems to generate compiler errors for
> some compilers is the use of Fortran 90 comments BUT Fortran 77 continuation
> notation (+'s in column 6). It helps in this case to name the source
> file with an .F extension rather than .F90.
>
> Skip Knoble
>
Yep, I agree. If I can ever convince any of my fellow coders to use F95
styles, syntax, and features we'll be doing that. For now, the use of
certain Sun-provided extensions such as the ! comments gives us a bit of
a mixed bag...
Jim
>
> On Mon, 23 Jan 2006 14:04:32 GMT, "J.F. Cornwall" <JCornwall@cox.net> wrote:
>
> -|Hi all. We have just taken the long-overdue plunge and converted one of
> -|our development systems from the Sun F77 compiler (Forte 6.2) to the
> -|current SunStudio 11 suite. One of our team has found something that
> -|may be a conversion issue for his part of the code. We're not sure if
> -|it is a compiler-specific issue or something that's part of the F95
> -|standard. Test program that illustrates the question is below:
> -|
> -|{jcorn} hqsun3: % cat comp_test.f
> -| PROGRAM MAIN
> -| IMPLICIT NONE
> -| INTEGER*4 KNT, LNBLNK, I
> -| PARAMETER (KNT=3)
> -| CHARACTER LABEL(KNT)*40
> -| CHARACTER LLB(3)*40
> -| INTEGER*4 BB(KNT)
> -| DATA (LABEL(I), I=1, KNT)/
> -| + 'meth',
> -| + '',
> -| + ' '/
> -| DATA LLB/'', 'a', ' '/
> -|!
> -| WRITE (*, *) "Set A"
> -| WRITE (*, 100) LABEL(1), LNBLNK (LABEL(1))
> -| WRITE (*, 100) LABEL(2), LNBLNK (LABEL(2))
> -| WRITE (*, 100) LABEL(3), LNBLNK (LABEL(3))
> -|!
> -| WRITE (*, *) "Set B"
> -| WRITE (*, 100) LLB(1), LNBLNK (LLB(1))
> -| WRITE (*, 100) LLB(2), LNBLNK (LLB(2))
> -| WRITE (*, 100) LLB(3), LNBLNK (LLB(3))
> -|!
> -| 100 FORMAT ('string: ', A, ' length: ', I2)
> -|
> -| STOP
> -| END
> -|
> -|{jcorn} hqsun3: % f77 -V
> -|NOTICE: Invoking /opt/SUNWspro/bin/f90 -f77 -ftrap=%none -V
> -|f90: Sun Fortran 95 8.2 2005/10/13
> -|Usage: f90 [ options ] files. Use 'f90 -flags' for details
> -|{jcorn} hqsun3: % f77 -o comp_test comp_test.f
> -|NOTICE: Invoking /opt/SUNWspro/bin/f90 -f77 -ftrap=%none -o comp_test
> -|comp_test.f
> -|comp_test.f:
> -| MAIN main:
> -|{jcorn} hqsun3: % comp_test
> -| Set A
> -|string: meth length: 4
> -|string: length: 40
> -|string: length: 0
> -| Set B
> -|string: length: 0
> -|string: a length: 1
> -|string: length: 0
> -|{jcorn} hqsun3: %
> -|
> -|Jim (another one, not me) was expecting a length of zero for hte second
> -|item in Set A. Instead he got 40... This is the one initialized with
> -|the '' expression inside the implied-do loop in the DATA statement.
> -|
> -|In Set B, the same use of '' in a plain old DATA statement without the
> -|loop results in a zero length.
> -|
> -|Is this behaviour part of the standard or something compiler-specific?
> -|
> -|Jim Cornwall
>
| |
| Richard E Maine 2006-01-23, 7:04 pm |
| Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu> wrote:
> Richard: If the file extension is .F all compiler that I know of will
> compile the code. If the file extension is .F90, I know of no compiler
> which will accept the F77 continuation. This includes g95.
That's just because you have (implicitly) told it that the code is in
free source form. This has nothing to do with mixing fixed source form
with "!" comments. It is purely and simply a case of specifying
(implicitly) the wrong source form.
P.S. I do know of compilers that don't follow this convention for
indicating fixed vs free form, but that's a separate matter, and clearly
most compilers do, with some variations in the exact extensions used.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| J.F. Cornwall 2006-01-23, 7:04 pm |
| Richard E Maine wrote:
> J.F. Cornwall <JCornwall@cox.net> wrote:
>
>
>
>
> 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
| |
| Richard E Maine 2006-01-23, 7:04 pm |
| J.F. Cornwall <JCornwall@cox.net> wrote:
> 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.
Ah. Sorry. I typed that on the fly without having a compiler check it
for me. And I left out a close parens. You added one in for me, but not
in the right place. It should be (still not checked with a compiler, but
reviewed by my eyes a bit more carefully)
WRITE (*, *) (ichar(LABEL(2)(i:i)), i=1,3)
That is, the (only) argument to ichar is label(2)(i:i). The rest of it
is just an implied DO, because ichar only does a single character at a
time. Ichar just gives you the integer indicating where in the collating
sequence the character is. The reason I suggest it is not because you
care about the collating sequence, but just because it will give you a
visible printable result, even for control characters. For a blank,
ichar will return the integer value... let's see, that would be... 32
(for ascii character sets, which yours is). So if you see any values
other than 32 from it, your character string has something that isn't
actually a blank internally, even if it prints out that way. A value of
0 might be one I would be particularly suspicious of.
But this is more out of curiosity than anything. I'm moderately sure the
original problem is a compiler bug. This just helps figure out more
precisely what the nature of the compiler bug is.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| J.F. Cornwall 2006-01-23, 7:04 pm |
| Richard E Maine wrote:
> J.F. Cornwall <JCornwall@cox.net> wrote:
>
>
>
>
> Ah. Sorry. I typed that on the fly without having a compiler check it
> for me. And I left out a close parens. You added one in for me, but not
> in the right place. It should be (still not checked with a compiler, but
> reviewed by my eyes a bit more carefully)
>
> WRITE (*, *) (ichar(LABEL(2)(i:i)), i=1,3)
>
D'OH! Yep, having that closing paren in the correct location makes a
difference...
> That is, the (only) argument to ichar is label(2)(i:i). The rest of it
> is just an implied DO, because ichar only does a single character at a
> time. Ichar just gives you the integer indicating where in the collating
> sequence the character is. The reason I suggest it is not because you
> care about the collating sequence, but just because it will give you a
> visible printable result, even for control characters. For a blank,
> ichar will return the integer value... let's see, that would be... 32
> (for ascii character sets, which yours is). So if you see any values
> other than 32 from it, your character string has something that isn't
> actually a blank internally, even if it prints out that way. A value of
> 0 might be one I would be particularly suspicious of.
>
> But this is more out of curiosity than anything. I'm moderately sure the
> original problem is a compiler bug. This just helps figure out more
> precisely what the nature of the compiler bug is.
>
Does indeed look like zeros...
{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
{jcorn} hqsun3: % comp_test95
Set A
string: meth length: 4
string: length: 40
0 0 0
string: length: 0
{jcorn} hqsun3: %
| |
| Paul Van Delst 2006-01-23, 7:04 pm |
| J.F. Cornwall wrote:
> Richard E Maine wrote:
>
>
> D'OH! Yep, having that closing paren in the correct location makes a
> difference...
>
>
> Does indeed look like zeros...
>
> {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
> {jcorn} hqsun3: % comp_test95
> Set A
> string: meth length: 4
> string: length: 40
> 0 0 0
> string: length: 0
> {jcorn} hqsun3: %
Man, think how much time you would have saved if the compiler filled the zero-length
string memory with ASCII 07 (BEL) rather than 00 (NUL). When you printed out the results,
you still would've gotten a computed length of 40, but you'd've been assailed with 40
beeps. :o)
cheers,
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
| |
| Richard E Maine 2006-01-23, 7:04 pm |
| J.F. Cornwall <JCornwall@cox.net> wrote:
> Does indeed look like zeros...
[code and most output elided]
Looks like a fine sample for a bug-report to me. It's the kind of small,
self-contained example that vendors tend to like a lot (with good
reason).
I notice that I got the 3 and 40  . In some sense, it would have
made more sense to print out 40 values from ichar instead of just the
first 3, but I think the first 3 tell the story pretty well anyway.
> string: length: 40
Ah. There's another hint, which I missed before, in the output line
above. But it just confirms the same diagnosis. Note that although
len_trim said the length was 40, you don't obviously see 40 characters
in the output. That's because the character at collating position 0 (aka
the C null char) often prints out as... nothing. Not even a blank. That
depends on details of the output implementation, but it is a common one.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Steven G. Kargl 2006-01-23, 7:04 pm |
| In article <dr3eeg$28u$1@news.nems.noaa.gov>,
Paul Van Delst <Paul.vanDelst@noaa.gov> writes:
> J.F. Cornwall wrote:
>
> Man, think how much time you would have saved if the compiler filled
> the zero-length string memory with ASCII 07 (BEL) rather than 00 (NUL).
> When you printed out the results, you still would've gotten a computed
> length of 40, but you'd've been assailed with 40 beeps. :o)
Not if you cut the wire to the internal speaker because of all the
obnoxious beeping from various utilities. :-)
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| J.F. Cornwall 2006-01-23, 7:04 pm |
| Richard E Maine wrote:
> J.F. Cornwall <JCornwall@cox.net> wrote:
>
>
>
> [code and most output elided]
>
> Looks like a fine sample for a bug-report to me. It's the kind of small,
> self-contained example that vendors tend to like a lot (with good
> reason).
>
> I notice that I got the 3 and 40 . In some sense, it would have
> made more sense to print out 40 values from ichar instead of just the
> first 3, but I think the first 3 tell the story pretty well anyway.
>
>
>
>
> Ah. There's another hint, which I missed before, in the output line
> above. But it just confirms the same diagnosis. Note that although
> len_trim said the length was 40, you don't obviously see 40 characters
> in the output. That's because the character at collating position 0 (aka
> the C null char) often prints out as... nothing. Not even a blank. That
> depends on details of the output implementation, but it is a common one.
>
Thanks to everyone. I'll pass it on to the original fella who had the
question and let him take it from there, since he's actually part of our
official Sun server support group. That, and he can change his code to
initialize with blanks instead of nulls if he doesn't want to wait.
Thanks again, all. I love the knowledge in this group!
Jim
|
|
|
|
|