|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sun Jun 07, 2015 2:00 pm Post subject: Compiler bug: only warning for variable used as Spec. Expr. |
|
|
FTN95 compiles the following subroutine code with only a warning.
Code: | integer function cbd ()
character*(MaxLng) text
cbd = len(text)/2
return
end
|
The code is in error because the length specifier for the variable "text" is neither a constant nor a dummy argument. The function is an external function, so there is no question of MaxLng being available by host or USE association.
For the same code, FTN77 says
Code: | 0002) character*(MaxLng) text
*** A constant expression must be used in this case
*** A constant expression must be used in this case
0003) cbd = len(text)/2
*** LEN is an intrinsic function used with invalid argument(s)
3 ERRORS [<CBD>FTN77 Ver 4.03] |
This compiler bug is at the heart of the rather long and devious discussion in a recent thread, "Attributes of File", at http://forums.silverfrost.com/viewtopic.php?t=3101
Last edited by mecej4 on Sun Jun 07, 2015 3:25 pm; edited 1 time in total |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sun Jun 07, 2015 3:05 pm Post subject: |
|
|
In my simple world, with implicit typing MaxLng is clearly INTEGER (good) but undefined (bad) with no route to define it. This depends on there being a simple scoping rule.
Under modern scoping rules MaxLng as I understand it could have been defined and initialised elsewhere, so surely this is evidence that the syntax check in FTN95 considers only what it finds inside an individual routine?
Eddie |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sun Jun 07, 2015 3:45 pm Post subject: Re: |
|
|
LitusSaxonicum wrote: | Under modern scoping rules MaxLng as I understand it could have been defined and initialised elsewhere, so surely this is evidence that the syntax check in FTN95 considers only what it finds inside an individual routine? |
No, and FTN95 could not even be called a Fortran-90 compiler with that limitation. The code given is a complete compilation unit. If the code is modified and augmented to
Code: |
module cnsts
integer, parameter :: MaxLng = 132
end module
integer function cbd ()
use cnsts
character*(MaxLng) text
cbd = len(text)/2
return
end
program xcbd
integer cbd
print *,cbd()
end program
|
the modified program prints the correct result, "66". In this case, there is an "elsewhere", and the function could not have given the correct result without being given and without using the information in the module.
There is a twist in the modified program. The variable "text" is undefined, and the compiler issues a corresponding warning. However, the length of "text" can be deduced without having to know the value of "text", so no error occurs even if the program is compiled with /UNDEF.
Last edited by mecej4 on Sun Jun 07, 2015 8:35 pm; edited 1 time in total |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sun Jun 07, 2015 8:07 pm Post subject: |
|
|
You are right and I misunderstood. I now see "there is no question of MaxLng being available by host or USE association". It has to be an error not a warning.
The twist is interesting. |
|
Back to top |
|
|
AntonioGJerez
Joined: 01 Jun 2015 Posts: 9 Location: Spain
|
Posted: Sun Jun 07, 2015 10:10 pm Post subject: intent() |
|
|
A minor issue in a similar context: if ftn95 is used without flags (apart from /LINK), intent(out) clauses are ignored at compilation and at runtime. Nevertheless, a suitable runtime error is displayed if /CHECKMATE is used (a compilation error would be better). If intent(out) is replaced with an equally wrong "intent(in)", the error is detected in all cases.
Code: |
program test
real x
x=3
call sub(x)
print*,x ! Shows 5. Thus, sub uses the value in x in spite of intent(out)
end program
subroutine sub(x)
real,intent(out)::x
x=x+2
end subroutine
|
Last edited by AntonioGJerez on Sun Jun 07, 2015 10:41 pm; edited 1 time in total |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sun Jun 07, 2015 10:41 pm Post subject: |
|
|
I have a vague recollection of someone writing that specifying INTENT has the effect of placing restrictions on the programmer rather than the compiler. In fact, the F2008 standard says, in Note 5.17: "...A slightly more sophisticated processor could check to see whether an INTENT (OUT) dummy argument could possibly be referenced before it is defined."
In your example code, in addition to the INTENT error there is a questionable line of code. Strictly speaking, at entry to a subprogram an INTENT(OUT) variable becomes undefined, so assigning a value to x before the call is wasteful. Some compilers do catch such errors, but usually only if asked to do so. |
|
Back to top |
|
|
AntonioGJerez
Joined: 01 Jun 2015 Posts: 9 Location: Spain
|
Posted: Sun Jun 07, 2015 10:49 pm Post subject: |
|
|
OK,
On the other hand, a similar intend(in) error is thoroughly catched. Its seems very assymetric.
Note that at entry to my subprogram, the intent(out) variable x does not become undefined (maybe it should). The example has been chosen because I (a beginer in Fortran) was expecting an output x=2, x=undefined or an error message
Last edited by AntonioGJerez on Sun Jun 07, 2015 11:39 pm; edited 1 time in total |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sun Jun 07, 2015 11:27 pm Post subject: Re: |
|
|
AntonioGJerez wrote: | Note that at entry to my subprogram, the intent(out) variable x does not become undefined (maybe it should). |
Here is what the Fortran 95 Standard says in section 5.1.2.3:
"The INTENT (OUT) attribute specifies that the dummy argument shall be defined before a reference to the dummy argument is made within the procedure and any actual argument that becomes associated with such a dummy argument shall be definable. On invocation of the procedure, such a dummy argument becomes undefined except for components of an object of derived type for which default initialization has been specified."
However, since it takes a lot of extra machine code to make things work as specified in the last sentence of the quotation, few compilers implement the standard literally unless an option such as /CHECKMATE or /UNDEF is specified. |
|
Back to top |
|
|
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Wed Jun 10, 2015 7:08 pm Post subject: |
|
|
With INTENT(OUT) the user has an obligation not to reference the variable unless he/she first defines it. Formally he/she must assume the variable is undefined when the subroutine or function is entered.
If you do reference the variable without first defining it, then you, the programmer, is at fault. In such cases, the compiler (strictly the Fortran Processor) can do anything it wants. With FTN95 and /CHECKMATE the compiler will detect such events at run time (in most cases, there are a few corner cases that don't work properly).
The case of INTENT(IN) is completely different and isn't particularly a symmetric case to INTENT(OUT). INTENT(IN) is used to direct the programmer not to make any change to the variable, or to pass it to another subroutine or function where the dummy argument has the INTENT(IN) or INTENT(INOUT) attribute.
The compiler can usually check at compile time for most cases where the INTENT(IN) attribute is not respected by the programmer. One case where the compiler may not diagnose a programmer's error is when the variable is subsequently passed to an external subroutine or function which does not have an explicit interface where the corresponding dummy argument has the INTENT(OUT) or INTENT(INOUT) attribute.
In all cases, it is up to the programmer to ensure the code complies with the standard (and any extensions provided by Silverfrost). The compiler and run time systems can help but can't enforce compliance in all cases. _________________ Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|