How this error even can appear?

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

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).

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

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 )

Personally I don't believe that GIGOs are generally more active at the weekend unless that is when you do most of your programming.

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 😃

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)...

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.

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.

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:

             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 !

Dan, the following code extract illustrates the issue.

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?

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

Ah, I see. Perhaps, if the error message had said 'referenced' instead of 'used' the meaning would have been clearer to you?

Mecej4, are you British ? 😃 Yes, 'referenced' is better.

But not perfect.

Look at this file with my problem clearly exposed

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

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

    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