View previous topic :: View next topic |
Author |
Message |
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Wed Jun 12, 2019 1:09 pm Post subject: Bug with LEN in 8.50 |
|
|
If you try the following code in 64bit
Code: | !ftn95$free
subroutine test_len(i, j)
integer k
k = i+j
end
program test
CHARACTER*18 :: PRF(3)=['Direct proof ', 'Intermediate proof', &
'Indirect proof ']
i = 1
j = 2
call test_len(i,j)
call test_len(i,len(prf))
end |
You get the following warning
Code: | WARNING - 189: In a previous call to TEST_LEN, the second argument was of type INTEGER(KIND=3), it is now INTEGER(KIND=4) |
Surely LEN is always KIND=3 ? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Wed Jun 12, 2019 2:00 pm Post subject: |
|
|
Yes you are right at least when you use /ISO on the command line. I will make a note that this needs fixing.
You can avoid the warning by changing to len(prf,3).
As in the case of SIZE, FTN95 does not conform to the Standard in this respect but ought to when /ISO is used on the command line. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Jun 13, 2019 7:54 am Post subject: |
|
|
The documentation for /ISO states:
Quote: | /ISO
Ensures that all constructs used in a program conform to the Fortran 95 ISO Standard. The /ISO option also informs the FTN95 run-time system that ISO-conformity is required. This means that, for example, non-standard use of format descriptors (such as business editing in a run-time format) causes a run-time fail ure. |
So, does it mean that the compiler auto-modifies the code to comply with the Standard (as the last line of your reponse above implies ?) or does it mean that checking will be performed to identify if the code complies with the standard and if not it will be highighted and compile will fail (which is how I read 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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Thu Jun 13, 2019 8:06 am Post subject: |
|
|
I will take a chance and assume that you are not "pulling my leg"...
No FTN95 is not clever enough to modify the code to conform nor would that be helpful to the user who wants to know if their code is portable. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 13, 2019 10:09 am Post subject: |
|
|
Paul, John-Silver,
I also was confused about the word "Ensures" in the documentation John quoted. For me "ensures" is something active like "guarantees" which I think is not meant, is it? I would prefer substituting "ensures" by "expects" in the quote. However, I am no native speaker
The online help of ftn95 (ftn95 /?) says:
Code: | /ISO Use strict ISO Fortran 95 rules, no extensions allowed |
which I find more intuitive.
Regards,
Dietmar |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 13, 2019 10:29 am Post subject: |
|
|
Hello,
one more remark concerning the debugger in this context: I am not able to set a breakpoint to the end statement of subroutine test_len using sdbg64, hence I cannot see the outcome of the assignment in the last call of test_len in sdbg64. Moreover, if sdbg64's mouse cursor hovers above a variable, say j, then the value of j is displayed. If moving the mouse cursor to variable i and then moving it back to variable j again, then the value of j is not displayed again for sdbg64.
Both is different to the 32 bit version of the debugger (sdbg).
Regards,
Dietmar |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 13, 2019 1:21 pm Post subject: |
|
|
Sorry, I just made a mistake in my last post where I complained about the sdbg64 variable j which I said was not dispayed a second time
The correct scenario for sdbg64 is the following:
1. make the cursor hover above variable j hence the value of j is shown
2. move the cursor away from variable j until the value of j disapperars, but do not make the cursor hover above another variable
3. move the cursor back to variable j again;
Now from the 32 bit version of the debugger I would expect the value of j be displayed again. However, this is not the case for sdbg64.
I like this feature very much
Sorry and regards,
Dietmar |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Tue Jul 09, 2019 3:26 pm Post subject: |
|
|
The original problem (when LEN is called in 64 bit code as the value of an argument) has now been fixed for the next release of FTN95. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Tue Jul 09, 2019 6:48 pm Post subject: |
|
|
Paul,
It's a word choice. I see on the front page that FTN95 is:
Quote: | Welcome to the home of Silverfrost FTN95: Fortran for Windows (formally Salford FTN95). We let you use Fortran your way: |
and I keep wondering if 'formerly' is meant.
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean � neither more nor less."
"The question is," said Alice, "whether you can make words mean so many different things."
"The question is," said Humpty Dumpty, "which is to be master � that's all." (Looking-Glass 6.63-65)
Eddie (in leg-pull mode) |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Wed Jul 10, 2019 7:31 am Post subject: |
|
|
Ah yes. Thanks for letting us know. |
|
Back to top |
|
|
|