Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28469 Discussions

error while compiling a long program

Francisco3
Beginner
831 Views

Hi,

 

I am trying to compile a large Fortran program with Intel Fortran Compiler 2023.2.0 on Ubuntu 22.04. The message I get is:

ifort: error #10105: /opt/intel/oneapi/compiler/2023.2.0/linux/bin/intel64/../../bin/intel64/fortcom: core dumped
ifort: warning #10102: unknown signal(0)
ifort: error #10106: Fatal error in /opt/intel/oneapi/compiler/2023.2.0/linux/bin/intel64/../../bin/intel64/fortcom, terminated by unknown
compilation aborted for program_NM_Ellis_WH_polar_right1_sine.f (code 1)

 

Compiling smaller programs works fine. Does anyone have an idea about the problem I am having? Thank you very much.

0 Kudos
1 Solution
jimdempseyatthecove
Honored Contributor III
789 Views

Keep in mind that .f file extension specifies fixed form source format.

If the program was compiling before a recent edit, but does not now compile, I suspect the editor (or you) have done something to vary from the fixed form source format. For example, replacing multiple spaces with TAB character(s), or inserting non-ANSII characters supported by Fortran.

The error reports from these types of input errors should not crash the compilation, rather it should emit a proper error message. However, due to the size of the program, something else is likely amiss.

 

At 34835 lines, you should be able to split it into two or more pieces.

 

A first attempt, which can be easy to implement (under 5 minutes), is to use contained procedures. Sketch:

 

program bigProgram
  use YourModulesHere ! optional
  real :: ...
  ... !declarations here
  call part1
  call part2
  return
12345  FORMAT(... ! place formats before contained procedures.
contains
  subroutine part1
  ... ! code for part 1
  end subroutine part2
  
  subroutine part2
  ... ! code for part2
  end subroutine part2
end program bigProgram

 

Note, above is sketch. For fixed form, assure proper spacing.

Also, selection of specific sections of code will/may depend on DO loops and GOTO labels

Jim Dempsey

View solution in original post

0 Kudos
6 Replies
andrew_4619
Honored Contributor II
828 Views

That isn't much of a clue. What do you mean by long? I compile files with 20000+ lines every day that isn't an issue.  If you can break the file in two parts and see if they compile. The problem is more likely to be something in the file so a binary chop on the file to home in on what that is, is often the best way.

0 Kudos
Francisco3
Beginner
795 Views

Thank you for your answer, andrew4619.

The file has 34835 lines. I do not think the problem is in the code. I can mimic some subroutines so that the size reduces a bit, and then it compiles. But the substituted subroutines are fine, so the problem is not in those subroutines.

What does this error message really indicate?  I am puzzled. Thank you again.

0 Kudos
jimdempseyatthecove
Honored Contributor III
790 Views

Keep in mind that .f file extension specifies fixed form source format.

If the program was compiling before a recent edit, but does not now compile, I suspect the editor (or you) have done something to vary from the fixed form source format. For example, replacing multiple spaces with TAB character(s), or inserting non-ANSII characters supported by Fortran.

The error reports from these types of input errors should not crash the compilation, rather it should emit a proper error message. However, due to the size of the program, something else is likely amiss.

 

At 34835 lines, you should be able to split it into two or more pieces.

 

A first attempt, which can be easy to implement (under 5 minutes), is to use contained procedures. Sketch:

 

program bigProgram
  use YourModulesHere ! optional
  real :: ...
  ... !declarations here
  call part1
  call part2
  return
12345  FORMAT(... ! place formats before contained procedures.
contains
  subroutine part1
  ... ! code for part 1
  end subroutine part2
  
  subroutine part2
  ... ! code for part2
  end subroutine part2
end program bigProgram

 

Note, above is sketch. For fixed form, assure proper spacing.

Also, selection of specific sections of code will/may depend on DO loops and GOTO labels

Jim Dempsey

0 Kudos
Francisco3
Beginner
752 Views

Hi Jim,

Thank you very much for your answer. Yes, definitely the program is not optimized at all. I am not a programmer, but I only use Fortran programs to study Physics problems. This one is a huge one, and that is the reason for such a huge code. Most of the subroutines are generated by Maple so I have not typed all the code, of course. So I cannot change their size. But I can change the structure of the program. I will do that following your suggestions, to see if the error disappears. Thank you again.

Francisco

 

 

0 Kudos
mecej4
Honored Contributor III
737 Views

When a compiler aborts with a segfault or core dump, a compiler bug has surfaced. However, it is possible to investigate the bug only if the candidate program source is available. Please zip up your source code and attach the zip file in a reply here. In the reply, list the compiler version used and the options specified for the compilation that failed.

0 Kudos
Francisco3
Beginner
571 Views

Hi mecej4,

 

Sorry for the delay (I was on vacation). I managed to solve the problem with the compilation of the program. I split the code in several subroutines and, in the end, everything worked fine. There were no syntax errors. It was just an excessive length (I guess). The main part of the code was generated with Maple so I had to tell Maple how to split the output into several pieces.

Thank you very much for all your responses. 

0 Kudos
Reply