Dear Intel Fortran Compiler Support team,
I'm a member of a research group who is developing its own research software using the lastest features of the Fortran standard. This code succesfully compiles using the GNU Fortran compiler (version 5.X or 6.X), but while compiling with Intel Fortran Compiler (version 16.X or 17.X) we are experiencing an Internal Compiler Error.
We are compiling the code with 2 different sets of compiler flags:
- -r8 -fpp -W1 -fPIC -assume realloc-lhs -O3
- -r8 -fpp -W1 -fPIC -assume realloc-lhs -O0 -traceback -g -debug all -check all,noarg_temp_created -ftrapuv -warn nointerfaces
and with both we get the following message:
"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."
The point where the ICE occurs contains highly intrincated module dependencies and we are not able isolate this piece of code or to reproduce the ICE with a minimum sample code.
Currently, our code is not in the public domain yet, could it be possible that you take a look to this issue? If yes we could share with you the source code and compiling instructions using e.g. email
Thank you very much for your attention.
Best regards,
Víctor.
連結已複製
If you don't want to make the source public, you have available the option of filing a problem report on premier.intel.com using your support account. If you haven't registered your ifort license, you may create your support account at https://registrationcenter.intel.com
Dear Tim and Steve,
Currently we are using the Intel Fortran Compilers installed in an HPC cluster. I think that we cannot use Intel Premier Support.
¿is there another possibility to share the code with you?
Best regards,
Víctor
Where you're using it makes no difference. All that matters is what kind of license you have and if the support term is current. If you were able to download and install 17.0.1 then your support is current. If you want to send to me by email, send to steve.lionel [at] intel dot com. Please send the minimal files needed to reproduce the error. If it's more than one file, put them in a gzipped tar file.
Dear Steve,
finally i was able to isolate the ICE reproducer in the code snippet below.
module base_static_triangulation_names
implicit none
private
type cell_accessor_t
private
class(base_static_triangulation_t), pointer :: base_static_triangulation
contains
procedure, non_overridable :: get_num_vefs => cell_accessor_get_num_vefs
end type cell_accessor_t
type base_static_triangulation_t
contains
procedure, non_overridable, nopass, private :: cell_unpack => bst_cell_unpack
end type base_static_triangulation_t
public :: base_static_triangulation_t
public :: cell_accessor_t
contains
pure function cell_accessor_get_num_vefs (this)
class(cell_accessor_t), intent(in) :: this
integer :: cell_accessor_get_num_vefs
cell_accessor_get_num_vefs=0
end function cell_accessor_get_num_vefs
subroutine bst_cell_unpack (cell, buffer, vef_gids, vef_dimensions, coordinates)
type(cell_accessor_t), intent(inout) :: cell
integer, intent(in) :: buffer(:)
integer, intent(out) :: vef_gids(cell%get_num_vefs()) ! <- I think that the problem is in the use of this pure function here
integer, optional, intent(out) :: vef_dimensions(cell%get_num_vefs()) ! <- and here
real, optional, intent(out) :: coordinates(3,cell%get_num_vefs()) ! <- and here
vef_gids = 0
end subroutine bst_cell_unpack
end module base_static_triangulation_names
module fe_space_names
use base_static_triangulation_names
implicit none
private
type, extends(cell_accessor_t) :: fe_accessor_t
end type fe_accessor_t
end module fe_space_names
