Capture ifort's exit code

Capture ifort's exit code


I would like to ask if there a way for the system to capture ifort's exit code for use in a variable (in a bash script)?

I am writing a bash script to compile several sources, and execute them right after each compilation. Since this script is run several times on the same path, usually because I am debugging the source bundle, the executable files are simply overwriten every time compilation succeeds for the respective sources.

Problem: A particular source file throws compilation errors and compilation is aborted. However the executable is still run on the follow-up, because the executable is found in path from previous successful compilations. For that reason I wish to skip execution every time compilation fails for a particular source, but have no elegant way to do it. Right now, I capture stderr to read the "compilation aborted" sub-string as a condition.

It would be particuarly useful to capture ifort's exit code instead. Besides it being more elegant, it can be more manipulative to (thinking about future projects), as the exit codes are differentiated for a reason. (not just 0 or 1)

Thanks in advance!

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Best Reply

The ifort exit code would be available under bash via $? which expands to the exit status of the most recent executed command. I believe that is also the value appearing in the "code" string on the compilation aborted message which I think is what you are after.

Inside the bash script you can capture the ifort exit status with something like:

ifort -c sample.f90


I came across $? in a sea of responses in stackoverflow regarding capturing the output of commands in general, and did not pay more attention to it. Thank you for your response.

It would not hurt to pre-delete the executable when doing a new build of the executable. Reason - having an executable laying around makes one assume it is consistent with the source code.

That... is a very good point. In my case however, the moment it's safe to remove the binaries is the moment the code is ready to compile anew, so the two suggestions are not essentially different in what I am doing, more so because I have this process automated (compile and execute in one bundle, because I make frequent changes) Thinking that I also have all the generated data files lying around, getting overwritten on every run, I think I''ll just stick to the exit code for the time being.

Many thanks for your reply, because you are right about cleaning obsolete binaries (most appropriately the moment you start commiting new changes to the source).

An issue you may wish to avoid is, should you make a change to the source (say just after copying your development folders to your new system), and should you have a path or missing include files, then the compilation will fail... leaving the old executable laying around. At this point, should the error be overlooked, you would have a situation where an out-of-date library or executable might "escape" from your control.

By pre-deleting the files, there would be nothing to escape.

An example of this: You are on vacation, you get a problem report from your office, you instruct a junior programmer to make the fix, they erroneously make the fix, run the build, not observe the error, issue an update using the prior build. Customer not satisfied, you spend hours trying to analyze error under assumption new code is in place. Ruined vacation - irritated customer - irritated boss.

In MS Visual Studio you can set pre-build events, with MAKE files you can essentially do the same thing.

Jim Dempsey

Leave a Comment

Please sign in to add a comment. Not a member? Join today