|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2866 Location: South Pole, Antarctica
|
Posted: Wed Nov 01, 2023 11:24 pm Post subject: How this error even can appear? |
|
|
Code: | 15624) 24301 print*, 'Err301 Can not read file'
*** Error 141: Label 24301 has been used outside the block IF starting on line 15254 |
If i remove the entire block with this error i get another similar one but now with DO loop, telling that the label is outside some DO loop
Why the heck i get these errors? What, I can not put labels wherever i want ?
I see strange things in this subroutine with IF/ENDIF not matching according to FTN95 and KATE editor but so far could not find this bug. Fun is that little bit older program with the same not matching IF/ENDIF working OK. Comparisons of new and old program shows all new added code has perfectly matching IFs/ENDIFs... All that makes me crazy.
Looks like i missed ENDIF somewhere.
And though i hate this but looks like I need to start writing codes using multiple smaller subroutines, otherwise i really can not locate any errors anymore. Even using several compilers. It is an absurd to spend whole day on that as if we live forever...
Potentially the big reason of many of my "devilries" are the style of programming. When the source code becomes enough long any small mistake causes total devastation
UPDATE
Or devilry is still a devilry ?
I found hundreds of file distortions comparing files i saved for reference while editing. After rebooting computer despite all these differences (all were just added space in numerous lines) the file compiled without any problems.
I had before similar unexplained problems in Windows which after reboot disappeared. But i've never seen such massive file corruptions |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Thu Nov 02, 2023 10:44 am Post subject: |
|
|
If the statement numbered 24301 is within an IF...ENDIF block, you are not allowed to transfer to that statement from a location that is outside the IF block.
Please provide access to the full source code of the program unit in question, or at least show all the lines that contain "24301" as a label (statement or target of GOTO). |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2393 Location: Yateley, Hants, UK
|
Posted: Thu Nov 02, 2023 4:26 pm Post subject: |
|
|
Dan,
The devilry that you so often encounter is probably the result of the satanic rituals implicit in your programming style.
A sprinkling of the following holy water may help:
Keep the subprograms short.
Use plenty of white space in your statements and in the subprograms as a whole.
Use statement numbers sparingly, and with a regular �stride� (say 10) through the program.
Use lots of comments.
Use short lines.
In WINIO@ calls, use few format codes.
Don�t include FORMAT statements adjacent to the READ or WRITE, instead, sequence them in a way that relates to what they do (e.g. 500 plus for READs, 600 plus for WRITEs) and put them in a bunch at the end of each routine.
Keep statements short by extracting common expressions yourself, instead of relying on the compiler to do it.
OK, some of these things might just increase run time, but that�s offset by making the incantation (sorry, Fortran) easier to read.
My religion also requires me not to use most of the blasphemy of Modern Fortran!
Eddie |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2866 Location: South Pole, Antarctica
|
Posted: Thu Nov 02, 2023 9:48 pm Post subject: |
|
|
Thanks mecej4 and Eddie for help and suggestions. Right now my assessment of the problem is that my file was somehow corrupted on massive, massive scale due to ... hell knows what.
As i have now no choice as to scale back to older variants, hopefully i will find on the way the actual place with an error otherwise i will post the offended subroutine with declarations and related functions.
Guessing was distortion of file because the RAM memory has no checksum, or my harddrives are now mostly flash based and hence more error prone, or Linux (and Windows under it) "sneezed"? I tortured it heavily last months, it was working with all its cores day and night, using all the memory and swap space, generating many terabytes of data. May be most reliable version of Linux is also needed, the RedHat, not Linux Mint (which has the best GUI interface and is the most user friendly but has its small problems too like all other Linux distros have but in general it's OK, at least it's better than Windows 10. The one major problem of Linux, specifically Ubuntu and related like Mint, is that it can be easily destroyed with what you download and install from the net, so you have to be careful by using only recommended software. Huge respect is for Android - my cell phones based on Android which based on Linux never had a single hiccup with 1000s installed programs in a decade. I would gladly switch on it, it will kill all other Linux distros eventially. Mint was losing twice in a year its graphics interface called GRUB, forcing to reboot ) |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8017 Location: Salford, UK
|
Posted: Fri Nov 03, 2023 7:54 am Post subject: |
|
|
Personally I don't believe that GIGOs are generally more active at the weekend unless that is when you do most of your programming. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2866 Location: South Pole, Antarctica
|
Posted: Fri Nov 03, 2023 3:33 pm Post subject: |
|
|
Little who knows this secret. Weekends and holidays are special times for those who use supercomputers. And in older days mainframes. Often during these weekend couple days when computers complete (or end up in errors) most other users runs you could grab more CPU time for your own runs than in the entire week of other working days.I use this trick for 50 years
Another explanation for devilry is that on weekend when nothing disturbing you with the calls and emails you start thinking more broadly and try some new stuff. And all we know - as soon as we step just tiny turn out of some proven general path you immediately get a million of problems
There exist also third, funny reason. At some point 20 years ago i thought i am together with FTN95 so great at finding any errors in any codes -- the FTN95 with /undef was literally humiliating many programmers finding tons of errors in their codes -- that even label 666 will not do anything if i will use it. And all you now know what happened after that. Psychology hints that pride, hubris, arrogance are punishable. And so tell many religions, but i did not care because i am an atheist. But if think more the Fermi Paradox tells that what i call devilry actually is not impossible
/* Eddie - you have to add words about label use to your list |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2866 Location: South Pole, Antarctica
|
Posted: Fri Nov 03, 2023 5:06 pm Post subject: |
|
|
Paul, By the way, where is in Plato if/endif checking? I can not find it in menu. I expected it works like in Kate editor (in Kate it's a great realization but i suspect it has a bug there. Or in my code. But code works somehow)... |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8017 Location: Salford, UK
|
Posted: Fri Nov 03, 2023 5:39 pm Post subject: |
|
|
Plato provides highlighting for most Fortran constructs. This feature can be switched on from the Settings dialog that is accessed from the Tools menu.
Just go to the section marked "Miscellaneous" and check the appropriate box.
At the moment, highlighting does not work for named constructs. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2866 Location: South Pole, Antarctica
|
Posted: Fri Nov 03, 2023 7:12 pm Post subject: |
|
|
Thanks. Plato works great, says no error.
Yea, i have to submit a bug report for Kate's if/endif checking. Lost two days on its devilry checking my devilry where the devil itself will break the leg. Otherwise it is great editor, very capable and stylish, i recommend. It's free by the way. Let's we all make it better by submitting to authors our bug reports and wishes. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2866 Location: South Pole, Antarctica
|
Posted: Fri Nov 03, 2023 8:11 pm Post subject: |
|
|
Bug found.
I indeed transferred code flow into the location of IF/ENDIF block which had label 24301 but that was done hiddenly in the READ statement in case of error so that i did not pay attention many times looking into it being shocked with the massive corruption of the file:
Code: | read(211,err=24301,end=243) emptyR8af, emptyR8bf |
Shouldn't FTN95 tell me exactly about that offending line instead of just expressing general Fortran rule? Is this doable? I understand mecej4 (thanks for the hint!) did not see the code, but FTN95 saw it ! I make such error second or third time and in every case spend a lot of time to find it. I know you can not jump from putside into DO/ENDDO loop but my impression was that with IF/ENDIF the rules were not that strict. This probably comes from older Fortran where there was no IF/END IF and where IF (A) GOTO 123 allowed to go anywhere you want besides DO lops.
Here as a comparison of two files in blue shown how many errors corruption caused just in this screen while there are 1000 of them. Tell me that was not a devilry !
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Sat Nov 04, 2023 12:20 am Post subject: |
|
|
Dan, the following code extract illustrates the issue.
Code: | subroutine sub(i,j,k)
implicit none
integer, intent(in) :: i,j
integer, intent(out) :: k
read(*,*,err=10,end=20)k
if(k > 0)then
10 k = i-j
else
20 k = i+j
endif
return
end subroutine |
According to the F95 standard, this code is incorrect:
"8.1.1.2 Control flow in blocks
Transfer of control to the interior of a block from outside the block is prohibited. Transfers within a block and transfers from the interior of a block to outside the block may occur."
The default options of some compilers, e.g., Gfortran, may let this code pass with only a warning, and you have to specify something similar to -std=f95 as an option to turn the warning onto an error.
I would not rely on a text editor to help me catch and fix such errors, especially when working with a large body of Fortran code. A Linux/Unix workstation provides us an excellent set of character mode tools for the task.
You asked, "Shouldn't FTN95 tell me exactly about that offending line instead of just expressing general Fortran rule?"
The FTN95 compiler gave you the line number 15624 in the error message. What more do you want? |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2866 Location: South Pole, Antarctica
|
Posted: Sat Nov 04, 2023 1:03 am Post subject: |
|
|
Who would expect editor has a bug? It hiccuped for the first time only on this piece of code.
Complicating also were that line 15624 was 10 miles after the offending line, the IF/ENDIF block contained 33 other IFs/ENDIFs and i am always in the hurry and always late .
Looks like i also misunderstood the Fortran rule about IF/ENDIF and the English of FTN95 with its error message. It sounded to me as contradicting reality and common sense: This label 24301 is inside IF/ENDIF block, hence it is used there, while compiler says it is used outside the IF/ENDIF block ! Pointing on offending READ statement with err=24301 is clearly needed.
I used heavily couple titles of software of British authors and i like both. What i do not like is their insistence on using words and manuals where showing examples would be much easier to the extent that the manuals and words would be completely redundant |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Sat Nov 04, 2023 10:29 am Post subject: |
|
|
Ah, I see. Perhaps, if the error message had said "referenced" instead of "used" the meaning would have been clearer to you? |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2866 Location: South Pole, Antarctica
|
Posted: Sat Nov 04, 2023 8:58 pm Post subject: |
|
|
Mecej4, are you British ? Yes, "referenced" is better.
But not perfect.
Look at this file with my problem clearly exposed
Code: | open (11,file='a')
read (11,*,err=11) a
close(11)
If(a.gt.1.) then
11 write(*,*) a
endif
end |
Its FTN95 diagnostics is done in true Shakespearean manner when you have to image the whole Universe for catching its sense
Code: | 0005) 11 write(*,*) a
*** Label 11 has been used outside the block IF starting on line 4
1 ERROR [<main program> FTN95 v8.97.2]
*** Compilation failed |
Its diagnostics with gFortran gives just the warning but code works, which is not the major point in this post, but major point is that it **points** at the warning source in addition to telling the Fortran rule and mentioning it is a legacy rule
Code: | 2 | read (11,'(a)',err=11) a
| 2
......
5 | 11 write(*,*) b
| 1
Warning: Legacy Extension: Label at (1) is not in the same block as the GOTO statement at (2)
|
That, perhaps better expressed as only true British can do, is what ideal diagnostics would be. If FTN95 prohibits jumping inside IF/ENDIF it has to point at the READ statement as the source of the error. One time showing is better than 100 sayings. But all British seems are in love with their language and doing exactly opposite |
|
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
|