View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Jan 19, 2021 12:41 pm Post subject: Compiler ignores syntax error with /opt |
|
|
The following test program contains a syntax error, as shown in the end-of-line comment. FTN95 8.70 compiles the program to an EXE when the /opt option is specified, with or without /64.
Code: | program tst
implicit none
integer, parameter :: N = 10
integer i
real,dimension(N) :: x
real :: x0 = 2.3
!
x = [(0.5*i+0.2, i=1,N)]
if(all(x(i) > x0+1e-3))then ! syntax error, argument of ALL() must be array
print *,' All elements of x exceed x0 by a sufficient margin'
else
print *,' Some elements of x are too small'
endif
end program tst |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Tue Jan 19, 2021 1:24 pm Post subject: |
|
|
mecej4
Thank you for the feedback.
I will take a look at this to see if there is a simple fix.
In a similar situation that occurred recently, it proved to be extremely difficult to fix so the documentation has been revised to say that /opt should not be used during initial development. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Jan 19, 2021 2:41 pm Post subject: |
|
|
If it works, then surely it is an extension.
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Tue Jan 19, 2021 3:28 pm Post subject: |
|
|
Eddie
No, it just won't work. Some syntax checking is currently skipped when using /opt and the outcome is unpredictable.
mecej4
This and the earlier issue have now been fixed. A different day and some evidence of lateral thinking. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Jan 19, 2021 4:13 pm Post subject: |
|
|
Paul, thanks for the rapid resolution of the issue.
Eddie, please note that the index variable i is not defined when the IF clause is evaluated; given that error, an extension does not make sense.
Perhaps an explanation of how this statement was born may be useful. In the old F77 code, the work of the ALL ... statement was performed in a DO loop, with a short exit from the loop if/when an element did not satisfy the condition. When such a short loop exit was taken, the index i would not only have been defined but would have had a value in the range 1:N.
When I replaced the loop by the IF..ALL() statement, I should have removed the index (i), but did not, which caused the bug. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Jan 19, 2021 4:59 pm Post subject: |
|
|
I really appreciate the explanations, but then I would always have used a DO loop.
Eddie |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Wed Jan 20, 2021 8:43 pm Post subject: |
|
|
Eddie's Song
(he'll be changing his name to 'Frank' before we know it ! ) _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
|