View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Nov 29, 2018 5:54 pm Post subject: Mistyping IMPLICIT NONE as IMPLICIT ONE causes ICE |
|
|
The following test code has NONE incorrectly keyed in as ONE in the second line. FTN95 8.30.279 aborts with an internal compiler error, and this is not affected by /64, /DEBUG, /CHECK, etc.
The code:
Code: | program doice
implicit one ! <<<=== 'none' mistyped as 'one'
real :: x
x=sqrt(3.14159)
print *,x
end program |
The compiler output:
Code: | S:\LANG\FTN95>ftn95 /check impone.f90
[FTN95/Win32 Ver. 8.30.279 Copyright (c) Silverfrost Ltd 1993-2018]
0002) implicit one ! <<<=== 'none' mistyped as 'one'
*** Internal compiler error
1 ERROR [impone.F90] - Compilation failed.
|
Last edited by mecej4 on Thu Nov 29, 2018 6:21 pm; edited 1 time in total |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Thu Nov 29, 2018 6:15 pm Post subject: |
|
|
... and so, for that matter, does
IMPLICIT OMPLEX (Z)
with presumably all sorts of spelling errors likely to do the same. Perhaps FTN95 no see the problem.
Joking apart, what follows IMPLICIT seems to need to be either NONE or a valid type name.
Eddie |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Nov 29, 2018 8:05 pm Post subject: Re: |
|
|
LitusSaxonicum wrote: | Joking apart, what follows IMPLICIT seems to need to be either NONE or a valid type name. |
Compilers are usually nonchalant when asked to compile text input that is not even program source.
Code: | S:\MATH\Luksan\PVAR\ORIG\yy\cull\POL>ftn95 /64 niger.f90
[FTN95/x64 Ver. 8.30.279 Copyright (c) Silverfrost Ltd 1993-2018]
0001) THERE was a young lady of Niger
*** Statement not recognised
0002) Who smiled as she rode on a Tiger;
*** Statement not recognised
0003) They came back from the ride
*** Statement not recognised
0004) With the lady inside,
*** Statement not recognised
0005) And the smile on the face of the Tiger.
*** Statement not recognised
*** Missing END statement
6 ERRORS [<main program> FTN95 v8.30.279]
*** Compilation failed |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Fri Nov 30, 2018 8:54 am Post subject: |
|
|
Thank you for the bug report. I have logged this as needing fixing. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Fri Nov 30, 2018 12:20 pm Post subject: |
|
|
Compilers may be nonchalant, but lovers of the limerick won't be with your example, as it isn't good form to use a same ending words for two (or more) rhymes. I thought that you 'program in lowercase' enthusiasts only capitalised function names, which makes the Tiger perhaps miss its (). Tiger in any case doesn't rhyme with Niger (except visually). There aren't all that many real rhymes with tiger - Eiger and Geiger perhaps, making Tiger a poor word choice to end the a lines.
Also, as we don't know about the lady's face, isn't the indefinite article more appropriate than the definite article in respect to the smile?
Also being serious (again, at last), is a statement that begins with something valid but then goes off piste a special case? FTN95 often treats spelling errors quite differently:
Code: | 0002) integer, externally :: Mecej4 ! <<<=== 'outside chance?'
*** ':' found after LY where a comma was expected |
versus
Code: | 0002) integer, eternal :: Mecej4 ! <<<=== 'ever yours'
*** Unknown or missing type declaration attribute specification after ',' |
These are certainly cases where the first name has been recognised for what it is. In the former, the non-significance of space characters clearly controls the error message generated, but I think that FTN95 would have to be very clever to do better in the latter (and then mark the spot with an x).
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Sat Dec 01, 2018 3:22 pm Post subject: |
|
|
This turns out to be simply an incorrect error report and not an "internal compiler error". The error report has now been changed to "Unexpected type in IMPLICIT list" for v8.50.
Last edited by PaulLaidler on Mon Dec 03, 2018 11:09 am; edited 1 time in total |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon Dec 03, 2018 12:26 am Post subject: |
|
|
WOW ! version 8.5 planned already, I'm impressed ! _________________ ''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 |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon Dec 03, 2018 12:45 am Post subject: |
|
|
what is in the main post:
Quote: | 0002) implicit one ! <<<=== 'none' mistyped as 'one'
|
seems to ìbe an almost perfectly good error message
Just missing the word 'maybe'
Of course a 'human' message would more completely be:
'Error in TYPE definition on IMPLICIT statement.
Maybe you meant to type NONE and have mis-typed ONE ? '
(yes I know, 2 lines, a bummer to program eh)
Of course this goes against the grain of programmers coding useful error messages ! LOL
I come from a brand of being who has often been befuddled by NASTRAN FE error messages, so I'm quite proactive in reading between the lines, but the rule of thumb should be 'error messages should be written to be understood by dummies' - we're not all androidic, well-programmed, thinkers.
Anyone using 'generic' error messages just to save on writing a few dozen more should be shot !
Come to think or it - is there a comprehensive list of ALL error messages that could be output from FTN95 et al somewhere ?
We could have a christmas quiz of 'Guess the error which corresponds to the message' , just for fun like. _________________ ''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 |
|
|
|