Fortran - g95 bug with ENTRY

Author

g95 bug with ENTRY

John Harper

2005-09-21, 9:57 pm

I'd normally just email the following to Andy Vaught but our email
system says andyv@firstinter.net has a permanent fatal error, so I'm
posting it here and hoping he (and anyone interested in ENTRY) sees it.

Have I found a new bug in g95? The f95 standard forbids
ENTRY enter RESULT (answer)
because Section 12.5.2.5 syntax rule R1225 says
ENTRY entry-name [([dummy-argument-list]) [RESULT(result-name)]]
which would require at least
ENTRY enter() RESULT (answer)

but g95 compiles and runs this program:

PROGRAM testentry
PRINT*,'funct=',funct() ! prints funct= 0.0000000
PRINT*,'enter=',enter() ! prints funct= 1.000000
END PROGRAM testentry
!
REAL FUNCTION funct()
funct = 0.0
RETURN
!
ENTRY enter RESULT (answer)
answer = 1.0
RETURN
END FUNCTION funct

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

[JvO]

2005-09-22, 6:58 pm

Not quite a bug, but, indeed, the error might be signalled by the
compiler.

[Jvo]

Richard E Maine

2005-09-22, 6:58 pm

In article <1127411301.653670.291550@o13g2000cwo.googlegroups.com>,
"[JvO]" <jvo_36@hotmail.com> wrote:

> Not quite a bug, but, indeed, the error might be signalled by the
> compiler.

I disagree with the "not quite a bug" part. The lack of parens means
that the code in question fails to conform to R1225 in f95 (that's the
bnf syntax for the ENTRY statement). R1225 is a numbered syntax rule as
mentioned in item (3) of 1.5, "Conformance". Thus a compiler is
nonconforming if it fails to have the capability of diagnosing this
error. I therefore claim that it counts as a compiler bug (i.e. failure
to conform to the standard).

In a different category from some other bugs, I'd agree. But I still
claim it counts as a bug. (But I bet it won't last long; one like this
shouldn't be hard to squash.)

--
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

Dick Hendrickson

2005-09-22, 6:58 pm

Richard E Maine wrote:
> In article <1127411301.653670.291550@o13g2000cwo.googlegroups.com>,
> "[JvO]" <jvo_36@hotmail.com> wrote:
>
>
>
>
> I disagree with the "not quite a bug" part. The lack of parens means
> that the code in question fails to conform to R1225 in f95 (that's the
> bnf syntax for the ENTRY statement). R1225 is a numbered syntax rule as
> mentioned in item (3) of 1.5, "Conformance". Thus a compiler is
> nonconforming if it fails to have the capability of diagnosing this
> error. I therefore claim that it counts as a compiler bug (i.e. failure
> to conform to the standard).
>
> In a different category from some other bugs, I'd agree. But I still
> claim it counts as a bug. (But I bet it won't last long; one like this
> shouldn't be hard to squash.)

It's a funny kind of bug. I've lost the original post
(someday I'll learn how to use these newfangled newsreaders).
But, IIRC, the line in question was something like

ENTRY some_name RESULT(answer)

and that's perfectly fine in fixed source form, isn't it?
Might be a little surprising in what it does, but the
syntax is clear.

Makes me wonder if R1225 is a well written rule. If I
understand it correctly, it's the only one I recall
that turns a bug into a feature depending on the source
form.

Dick Hendrickson
>

Richard E Maine

2005-09-22, 6:58 pm

In article
<X2EYe.296019$5N3.204340@bgtnsc05-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hendrickson@att.net> wrote:

> ENTRY some_name RESULT(answer)
>
> and that's perfectly fine in fixed source form, isn't it?
> Might be a little surprising in what it does,

Good point... though I had to think for a minute before I saw it. Almost
embarrassed myself (again :-)) by posting a completely clueless reply.

> Makes me wonder if R1225 is a well written rule....

Well, if one wants to critique things about the ENTRY statement... I've
got a little list. Um. Actually I guess it isn't that little of a list.
:-(

Maybe the whole thing should be made obsolescent. Um, wait... :-)

--
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

John Harper

2005-09-23, 3:58 am

In article <X2EYe.296019$5N3.204340@bgtnsc05-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
>But, IIRC, the line in question was something like
>
> ENTRY some_name RESULT(answer)
>
>and that's perfectly fine in fixed source form, isn't it?
>Might be a little surprising in what it does, but the
>syntax is clear.

Many things are valid in fixed but not free source form:
PRINT'(A)',' Hello World!'
FOR ALL
are cases in point, though there's no surprise about what they do.

Many things are valid in free but not fixed source form, e.g. letters
other than C in space 1, or & (not in a constant or comment) between
spaces 7,72.

Here's an f95 program valid in each form that does different things in
free and fixed source form. It has & in line 2 space 73, and + in line
3 space 6. Lines 1,2,4 start on space 7. It prints 6 if compiled in
free form, 8 if compiled in fixed form.
INTEGER :: j = 2, k = 4, jk = 8
PRINT *, j &
+ k
END

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

[JvO]

2005-09-23, 7:58 am

Dick Hendrickson schreef:

> Richard E Maine wrote:
>
> It's a funny kind of bug. I've lost the original post
> (someday I'll learn how to use these newfangled newsreaders).
> But, IIRC, the line in question was something like
>
> ENTRY some_name RESULT(answer)
>
> and that's perfectly fine in fixed source form, isn't it?
> Might be a little surprising in what it does, but the
> syntax is clear.

And the reference must be changed. :

print *, some_name result( )

Gives access violation.

Just as illustration, here my results with two versions
and three compilers:

PROGRAM testentry ! Unt.f95
implicit NONE
real, external :: funct, enter
PRINT*,'funct=', funct() ! prints funct= 0.0000000
PRINT*,'enter=', enter() ! prints enter= 1.000000
END PROGRAM testentry

REAL FUNCTION funct()
implicit NONE
real :: answer
funct = 0.0
RETURN

ENTRY enter RESULT (answer)
answer = 1.0
RETURN
END FUNCTION funct

! D:\Fortran\Test\Divers>g95 unt.f95
!
! D:\Fortran\Test\Divers>a
! funct= 0.0000000
! enter= 1.000000

! D:\Fortran\Test\Divers>f95 unt.f95
! cf90-197 error on line 14 of unt.f95: Unexpected syntax: "( or EOS"
was expected
! but found "R".
!
! f90: Copyright Absoft Corporation 1994-2002; Absoft Pro FORTRAN
Version 7.5a
! f90fe: 17 source lines
! f90fe: 1 Errors, 0 Warnings, 0 Other messages, 0 ANSI
! Execution of D:\Absoft\bin\f90fe.exe failed. Compilation aborted.

! D:\Fortran\Test\Divers>ftn95 unt.f95 /lgo
! [FTN95/Win32 Ver. 4.0.189 <martin> Copyright (C) Salford Software Ltd
1993-2003]
! Licensed to: Mr J. van Oosterwijk
! Organisation: TU DELFT
!
! NO ERRORS [<TESTENTRY> FTN95/Win32 v4.0.189 <martin>]
! 0014) ENTRY enter RESULT (answer)
! *** Invalid characters(s) after ENTRY statement, did you mean a
bracketed
! expression?
! 1 ERROR [<FUNCT> FTN95/Win32 v4.0.189 <martin>]
! *** Compilation failed

=====================

PROGRAM testentry ! Unt.for
implicit NONE
real, external :: funct, enter result
real :: q
PRINT*,'funct=', funct() ! prints funct= -1.000000
PRINT*,'enter=', enter result(q) ! prints enter= 1.000000
END PROGRAM testentry

REAL FUNCTION funct()
implicit NONE
real :: answer
real :: enter result
funct = -1.0
RETURN

ENTRY enter RESULT (answer)
answer = 1.0
enter result = answer
RETURN
END FUNCTION funct

! D:\Fortran\Test\Divers>ftn95 unt.for /lgo
! [FTN95/Win32 Ver. 4.0.189 <martin> Copyright (C) Salford Software Ltd
1993-2003]
! Licensed to: Mr J. van Oosterwijk
! Organisation: TU DELFT
!
! NO ERRORS [<TESTENTRY> FTN95/Win32 v4.0.189 <martin>]
! NO ERRORS [<FUNCT> FTN95/Win32 v4.0.189 <martin>]
! Creating executable: D:\Fortran\Test\Divers\lgotemp@.exe
! Program entered
! funct= -1.00000
! enter= 1.00000

! D:\Fortran\Test\Divers>f95 unt.for
! # link warning: file not needed for link - D:\ABSOFT\LIB\F90MATH.LIB
!
! D:\Fortran\Test\Divers>unt
! funct= -1.00000
! enter= 1.00000

! D:\Fortran\Test\Divers>g95 unt.for
!
! D:\Fortran\Test\Divers>a
! funct= -1.000000
! enter= 1.000000

[JvO] aka Jan van Oosterwijk

Dick Hendrickson

2005-09-23, 7:00 pm

John Harper wrote:
> In article <X2EYe.296019$5N3.204340@bgtnsc05-news.ops.worldnet.att.net>,
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
>
>
> Many things are valid in fixed but not free source form:
> PRINT'(A)',' Hello World!'
> FOR ALL
> are cases in point, though there's no surprise about what they do.
Yeah, my answer was a little bit overbroad. BUT, I still
think my example is more unusual than yours ;-) . Most of
the declaration rules have either syntax or constraints
designed to make sure that the statements mean the same
thing in either source form. The parens in PARAMETER or
the large number of sometimes required "::"s are to
guarantee disambiguity. There's an awful lot of syntax
rules designed to separate keyword-like things from user
names without depending on blanks. It's probably just me,
but putting a space in FOR ALL is different from putting one
in some_name RESULT(answer).

Off topic a bit, but have you tried
PRINT*,' Hello World'?
in both source forms? It's surprisingly(?) different from
your example.

>
> Many things are valid in free but not fixed source form, e.g. letters
> other than C in space 1, or & (not in a constant or comment) between
> spaces 7,72.
Yes, but those are explicit source form things, and it's not
surprising that they are different in the different source
forms ;).
>
> Here's an f95 program valid in each form that does different things in
> free and fixed source form. It has & in line 2 space 73, and + in line
> 3 space 6. Lines 1,2,4 start on space 7. It prints 6 if compiled in
> free form, 8 if compiled in fixed form.
> INTEGER :: j = 2, k = 4, jk = 8
> PRINT *, j &
> + k
> END
Neat example, I hadn't though of that.

Dick Hendrickson
>
> John Harper, School of Mathematics, Statistics and Computer Science,
> Victoria University, PO Box 600, Wellington, New Zealand
> e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Andy Vaught

2005-09-27, 7:02 pm

On Thu, 22 Sep 2005, Richard E Maine wrote:

> In article <1127411301.653670.291550@o13g2000cwo.googlegroups.com>,
> "[JvO]" <jvo_36@hotmail.com> wrote:
>
>
> I disagree with the "not quite a bug" part. The lack of parens means
> that the code in question fails to conform to R1225 in f95 (that's the
> bnf syntax for the ENTRY statement). R1225 is a numbered syntax rule as
> mentioned in item (3) of 1.5, "Conformance". Thus a compiler is
> nonconforming if it fails to have the capability of diagnosing this
> error. I therefore claim that it counts as a compiler bug (i.e. failure
> to conform to the standard).
>
> In a different category from some other bugs, I'd agree. But I still
> claim it counts as a bug. (But I bet it won't last long; one like this
> shouldn't be hard to squash.)

*squish* (and thanks to John Harper for sending it in)

Andy

Sponsored Links