forums.silverfrost.com

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

I found an inconsistency with /CHECKMATE and expressions as actual arguments. Smile

In the following two codes the argument (i) is an expression since i is in brackets.

In the first code (where i is undefined before the call to zzz), FTN95 correctly deduces that (i) cannot be evaluated since i is undefined and gives a run-time error with /CHECKMATE turned on.

PaulLaidler · Posted: Wed Dec 05, 2012 9:14 am Post subject:

I have noted your request.

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

I am resurrecting an old thread here.

In this code, where subroutine zzz has an explicit interface and uses intent(out), what is the correct treatment from the following list

- A result of 0 (this is the answer it gives)
- A result of 1
- Compile error

It is clearly (to me anyway Wink

) illegal code so I would have thought the third option.

I could understand if this was an extension and returned 1 (i.e. brackets are treated as superfluous and removed), but the subroutine returns 0.

mecej4 · Joined: 31 Oct 2006 Posts: 1899

I agree with you that the code is illegal. An INTENT(OUT) argument must be definable. An expression is not definable, so an expression cannot be the actual argument corresponding to an INTENT(OUT) dummy argument.

PaulLaidler · Posted: Tue Jan 20, 2015 12:06 pm Post subject:

This issue has now been fixed for the next release.
The compiler now reports an error condition for expressions whilst before it only complained when the argument was a constant value.

mecej4 · Joined: 31 Oct 2006 Posts: 1899

Paul, the issue reported at the beginning of this thread is still present in the 7.10 compiler.

PaulLaidler · Posted: Tue Jan 20, 2015 5:51 pm Post subject:

I had assumed that the two issues had the same cause and hence that both would be seen to be fixed in the next release. However it turns out that the first issue is still outstanding.

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Well I must admit to being a bit confused (again!).

As I understand it there are two issues:

(1) When an actual argument is a variable in brackets, the argument should be treated as an expression (I don't think the compiler vendor can do otherwise as an extension -- this is part of the Standard). In most cases compiling with /CHECKMATE will detect at run time any attempt to alter the value of an actual argument expression by assigning a value to the dummy argument. However in the special case of a bracket-variable-expression it doesn't work.

(2) When an explicit interface (e.g. through USE of a module) and intent(out) is used for the dummy argument, the compiler should be able to detect at compile time that it cannot pass a constant or expression as the actual argument. It should be able to do this regardless of whether /CHECKMATE is used or not. In the special case of a bracket-variable-expression it doesn't work.

These issues are similar but not the same. One is a limitation of the run time checking system, the other is a bug in the syntactical analysis of the compiler.

Run-time checking with /CHECKMATE happens even with an explicit interface since version 6.30 (see release notes). The run time checking may seem redundant in such cases but it allows the "constantness" of the variable to be checked if it is subsequently passed to an external subroutine/function without an explicit interface. Therefore for protection in all cases it is necessary that both (1) and (2) work.

It looks like Paul has fixed issue (2) but not issue (1). Perhaps you can confirm Paul ?
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

mecej4 · Joined: 31 Oct 2006 Posts: 1899

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

This is an interesting case.

FTN95 can catch such errors at run time if /CHECKMATE is used.

However, this is another case where widening the definition of what constitutes an actual argument expression would be helpful.

For now, changing the argument from i to i*1 allows the compiler to see it as an expression and issue an error.

I know that not all wrinkles in the compiler can always be patched but it is at least helpful to be aware of these shortcomings when programming.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

PaulLaidler · Posted: Wed Jan 21, 2015 9:30 am Post subject:

Going back to the original sample program on this thread where the INTENT is not specified and hence is unknown to the compiler, let me begin with a word of explanation for those reading this post who are less familiar with the details.

In the call to zzz, the argument is in brackets so the compiler treats this as an expression to be evaluated and stored as a temporary. The address of the temporary is passed to zzz where its value is changed. On return this value is "lost" and the value of i remains the same as before the call to zzz. If i is initially undefined (and /UNDEF is used) then there will be a run-time failure when i is printed. In other words, you get the value of i before the call.

Given that the later issue (where the INTENT is specified) has been fixed for the next release, as far as I understand it, that's the best the compiler can do. In order to flag an error it is necessary to specify the INTENT as OUT or INOUT. If the INTENT is unknown to the compiler then (at the point of call) it cannot assume that it is not INTENT(IN).

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

mecej4 · Joined: 31 Oct 2006 Posts: 1899

For both the test programs in the previous post, NAG Fortran says:

PaulLaidler · Posted: Mon Jan 26, 2015 8:40 am Post subject:

For me (i.e. using the pre-release version) there is no difference in the behaviour. So I think that you will find that there will be consistency here.

I am not sure why but this appears to be included in the current fix.

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK