- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The following part of our code does compile with ifort 11.1 (both MAC OS X and Linux) when compiling just with -c, but not with the -g -c flags. Also when compiling with -c only the produced module and object files seems to be incorrect, because our code crashed further on when calling the compiled module expressions.o.
The error when compiling with -g -c is:
ifort111: error #10105: /opt/ifort/intel/Compiler/11.1/038/bin/ia32/fortcom: core dumped
ifort111: error #10106: Fatal error in /opt/ifort/intel/Compiler/11.1/038/bin/ia32/fortcom, terminated by unknown signal(139)
compilation aborted for expressions.f90 (code 1)
Here is the code:
*****
module expressions
implicit none
private
type :: prt_t
private
integer :: type = 0
end type prt_t
type :: var_entry_t
private
integer, pointer :: ival => null ()
procedure(obs_binary_int), nopass, pointer :: obs2_int => null ()
type(var_entry_t), pointer :: next => null ()
end type var_entry_t
type :: var_list_t
private
type(var_entry_t), pointer :: first => null ()
end type var_list_t
abstract interface
function obs_binary_int (prt1, prt2) result (ival)
import
integer :: ival
type(prt_t), intent(in) :: prt1, prt2
end function obs_binary_int
end interface
contains
recursive function var_list_get_var_ptr (var_list) result (var)
type(var_entry_t), pointer :: var
type(var_list_t), intent(in), target :: var_list
var => var_list%first
end function var_list_get_var_ptr
end module expressions
*****
The error when compiling with -g -c is:
ifort111: error #10105: /opt/ifort/intel/Compiler/11.1/038/bin/ia32/fortcom: core dumped
ifort111: error #10106: Fatal error in /opt/ifort/intel/Compiler/11.1/038/bin/ia32/fortcom, terminated by unknown signal(139)
compilation aborted for expressions.f90 (code 1)
Here is the code:
*****
module expressions
implicit none
private
type :: prt_t
private
integer :: type = 0
end type prt_t
type :: var_entry_t
private
integer, pointer :: ival => null ()
procedure(obs_binary_int), nopass, pointer :: obs2_int => null ()
type(var_entry_t), pointer :: next => null ()
end type var_entry_t
type :: var_list_t
private
type(var_entry_t), pointer :: first => null ()
end type var_list_t
abstract interface
function obs_binary_int (prt1, prt2) result (ival)
import
integer :: ival
type(prt_t), intent(in) :: prt1, prt2
end function obs_binary_int
end interface
contains
recursive function var_list_get_var_ptr (var_list) result (var)
type(var_entry_t), pointer :: var
type(var_list_t), intent(in), target :: var_list
var => var_list%first
end function var_list_get_var_ptr
end module expressions
*****
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see this week's compiler failing when either debug symbols are requested or with the diag-enable sc option. So it does look like a good case for a formal problem report.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - tim18
I see this week's compiler failing when either debug symbols are requested or with the diag-enable sc option. So it does look like a good case for a formal problem report.
*****
bin/sh ../../libtool --mode=compile ifort -I../aux -I../vamp -g -c -o models.lo models.f90
libtool: compile: ifort -I../aux -I../vamp -g -c models.f90 -o .libs/models.o
fit_lookup: Line_seq_number 0x0 was not found
: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
*****
Again compiling without the -g flag goes thru. A little later however I encounter the following error message:
*****
/bin/sh ../../libtool --mode=compile ifort -I../aux -I../vamp -g -c -o quantum_numbers.lo quantum_numbers.f90
libtool: compile: ifort -I../aux -I../vamp -g -c quantum_numbers.f90 -o .libs/quantum_numbers.o
: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
*****
which is NOT resolved when compiling without -g.
This error occurs even for an empty file quantum_numbers.f90 with only a "use flavors" statement, so to me it seems that even when compiling without -g erroneous .o and .mod files are produced.
I'll try to isolate the problem.
BTW, how do I set up such a formal report?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You don't need to do that - reporting it here is sufficient. I'll pass this on to the developers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have reported the problem you described in the initial post as issue DPD200138085. Can you provide a test case for the other problem(s) you described?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This problem was fixed in Update 2.
![](/skins/images/D2683F18326913BBA0436CB7114DD569/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page