Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
27789 Discussions

Where is a Full List of Intel Fortran Run-Time Error Messages?


Hi everyone,


Doing a Google search throws up this List:


List of Run-Time Error Messages


The introduction reads:

"This section lists some of the errors processed by the compiler run-time library (RTL)."


Where is the Full List?




Labels (2)
0 Kudos
11 Replies

Thanks, Andrew.

Your link is effectively the same as mine.

The list does not include error no 408, for example:


forrtl: severe (408): fort: (2): Subscript #1 of the array KODE_FATIGUE_COMPONENT has value 1 which is greater than the upper bound of 0


Black Belt

There is a note a couple of lines below the heading in the page that is linked to your original post: "To see the full list of run-time errors, see file ifcore_msg.msg, which is located in the libraries part of your kit."

I do not see that file in any of the Parallel Studio versions that I have. 

In the HTML documentation for the compiler, it says, "This section contains information about understanding and handling compile-time and run-time errors", but there are only two links below that, neither of which has anything to do with run-time errors.

Sometimes, you web browser may be hindered from showing content because an ad-blocker thinks that the linked content is spam.

I downloaded the PDF version of the documentation, and found a list of error messages in it -- but no entry for 408.

Valued Contributor II

It was interesting this morning, to read this thread, the if thread and the AMPL thread from 2020. The missing error 408, represents one of the interesting problems, the ability to know that the code is correct and that the answer is correct and what is the most efficient way of getting a solution and finally that it has been documented properly. 

In terms of efficiency, a World bank economist was visiting a poor country, the people were digging a canal with shovels, and the gov official said the project employed a lot of people, the WBE said in that case why not use spoons. 

The thread yesterday, where it was suggested to use Python to solve a problem instead of Fortran, made me think of the WBE.  It is not only in computer programming that people accept a lot of waste for convenience. The classic problem for all FEM modellers is the ability to write the input file that can be huge and tedious and fraught with errors,  it is a trivial although slow task in Fortran to write a model generator that works from a simple input file, but I tried the same thing in Python a few years ago and it is much harder, because of the cycle time to review the results.  Once written the Fortran is orders of magnitude faster and cleaner in the coding and output. 

Behind all that we as a group and no matter what happens internally within the group, but as was once said in Australia, "they are a weird mob" at least we are being as efficient as possible and that is good. Even if we help the poor students who think that they can solve a billion element FEM in MATLAB if they try long enough.  The master's student of mine who tried that sort of exercise is now a Post DOC working on NASA problems. 

Although Prophets tend to fall on a sword. 

Valued Contributor II

With the 408 error, maybe we are just seeking the person at Intel who like the famous NASA error code 1202 has the answer written on a piece of paper, you just have to find the right person, and fast.  A classic human if statement if there ever was one. 

Black Belt Retired Employee

The list in the documentation is the best there is available. You can see a list of abbreviations for more in the include file for_iosdef.for, but there are no explanations. Oddly, number 408 there is not the same as you show.

There used to be an Intel Knowledge Base article with error messages, but no longer. If there's a message you don't understand, ask about it here. I would think that the array bounds error you give as an example is straightforward - it is one of the better messages, as many just have straight text.


One would think, in the age of AI, that someone at Intel could dump the compiler source into some AI-based software that could extract all the error messages?

My theory about the missing error numbers is that maybe they were stored in a Punched Card deck.

The deck was left on the floor of an unused office, subjected to silverfish invasion...

Black Belt Retired Employee

You CAN dump the compiler messages (/Qdiag-dump), but you didn't ask about a compiler message. What would a dump of the messages tell you that the printed text does not? I'd think you'd really want an explanation of what can cause the message to appear and how to fix it (if appropriate).

Valued Contributor II

Or we, the readers, can consider it just interesting evidence of human nature.  


I wonder how Intel counts the views on the forum, do you have to click on it, or are all the view counts advanced if one person opens the page.  Interesting thought on Saturday morning.  It flowed from looking at the views and then asking the question, I wonder how many "lurkers" to use an old computer term are on the forum.  

Of course one of the amazing things, is in the face of great challenges, @Steve_Lionel  keeps his cool in his post replies, you are a rare human, @Steve_Lionel . 


Hi Everyone,


I could live happily in an Intel Fortran world in which there is No list of run-time errors.

But it's human nature to be curious as to why the published list of "some of the errors" is grossly incomplete.


Black Belt Retired Employee

Because documentation is hard, and when developers add new messages they don't think to notify the writers to amend the list. What's even harder is explaining each message - I know, I tried for a while. It's not too bad when there are a hundred or so, but it gets much harder when the number increases a lot. The alternative is to not publish a list at all, which, sadly, seems to be the go-to solution (hence the disappearance of all the compiler error message web pages in the knowledge base here.)