[Regression Intel Fortran 11.1] Bug report

[jr_reuter]

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
*****

[TimP]

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.

[jr_reuter]

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.

In the meantime, I can add that when I comment out the -g flag and compile the expressions.f90 module without, then the next module crashes with the following error message:
*****
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?

[Steven_L_Intel1]

You don't need to do that - reporting it here is sufficient. I'll pass this on to the developers.

[Steven_L_Intel1]

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?

[Steven_L_Intel1]

This problem was fixed in Update 2.