- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am encountering a mysterious diagnostic
forrtl: severe (122): invalid attempt to assign into a pointer that is not associated.
in a rather large Fortran code on which I develop. It is mysterious because no pointers are involved. The abort line from the traceback is
656 current_sedc = sedc_calc
where "current_sedc" and "sedc_calc" are instances of a straightforward derived type containing small arrays and allocatable arrays of intrinsic types, logical, real, integer and character. No pointers, derived type components, classes, parameterization or anything fancy. current_sedc is a module-level declaration with the "save" attribute, and "sedc_calc" is a subroutine-scope declaration in the same scope as the assignment statement.
This error only occurs with very recent versions of both ifort and ifx, 2021.7.0 and 2021.7.1 (in oneAPI releases 2022.2.0 and 2022.2.1), and no abort was seen in any earlier version. It occurs at all optimization and debug levels. Furthermore it does not occur with any of the other four different Fortran compilers I have tried. Therefore I suspect a compiler bug.
It's a very large code, and unfortunately my attempts to boil down to a reproducible test case have failed. The only other diagnostic I have been able to obtain is a valgrind trace
==3441== Conditional jump or move depends on uninitialised value(s)
==3441== at 0x588A8CF: do_alloc_assign (in )
...
==3441== Use of uninitialised value of size 8
==3441== at 0x588A938: do_alloc_assign (in )
...
==3441== Invalid read of size 8
==3441== at 0x588A938: do_alloc_assign (in )
all at the call site reported by the diagnostic. By contrast, if I compile using 2022.1.0 and run under valgrind the run completes with no such diagnostics.
Any suggestions of how to proceed will be welcome. As I wrote above, the failure occurs only in the context of the whole program, and my efforts to encapsulate the offending code in a smaller example do not reproduce the issue.
Keith Refson
Link Copied
9 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apologies - completely botched the formatting there.
I am encountering a mysterious diagnostic
forrtl: severe (122): invalid attempt to assign into a pointer that is not associated.
in a rather large Fortran code on which I develop. It is mysterious because no pointers are involved. The abort line from the traceback is
656 current_sedc = sedc_calc
where "current_sedc" and "sedc_calc" are instances of a straightforward derived type containing small arrays and allocatable arrays of intrinsic types, logical, real, integer and character. No pointers, derived type components, classes, parameterization or anything fancy. current_sedc is a module-level declaration with the "save" attribute, and "sedc_calc" is a subroutine-scope declaration in the same scope as the assignment statement.
This error was introduced with recent versions of both ifort and ifx, 2021.7.0 and 2021.7.1 (in oneAPI releases 2022.2.0 and 2022.2.1), and no abort was seen in any earlier version. It occurs at all optimization and debug levels. Furthermore it does not occur with any of the other four different Fortran compilers I have tried. Therefore I suspect a compiler bug.
It's a large code, and unfortunately my attempts to boil down to a reproducible test case have failed. The only other diagnostic I have been able to obtain is a valgrind trace
==3441== Conditional jump or move depends on uninitialised value(s)
==3441== at 0x588A8CF: do_alloc_assign (in )
...
==3441== Use of uninitialised value of size 8
==3441== at 0x588A938: do_alloc_assign (in )
...
==3441== Invalid read of size 8
==3441== at 0x588A938: do_alloc_assign (in )
...
all at the call site reported by the diagnostic. By contrast, if I compile using 2022.1.0 and run under valgrind the run completes with no such diagnostics.
Any suggestions of how to proceed will be welcome. As I wrote above, the failure occurs only in the context of the whole program, and my efforts to encapsulate the offending code in a smaller example do not reproduce the issue.
Keith Refson
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@krefson ,
Since you write, "It occurs at all optimization and debug levels," I suggest you try your code with /check:all toward Intel Fortran run-time checking under Debug model (F5 key) in Microsoft Visual Studio on Windows OS if you're able to.
In many instances, the Visual Studio debugger traps the run-time exception right where it occurs and it shows you the code and the line where the exception got triggered and usually also the stack trace and the state and values of objects at the time of the exception. You can then try to work your way backward to try to determine the events that led to the exception.
Good luck,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did test this with full run-time checking on, and there is no difference in behaviour. The run is aborted by the RTL with
forrtl: severe (122): invalid attempt to assign into a pointer that is not associated.
at exactly the same line, namely
current_sedc = sedc_calc
where both LHS and RHS are define types without a pointer in sight. The types do contain allocatables though, but I believe the standard allows for assignment of a type containing an unallocated allocatable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>current_sedc is a module-level declaration with the "save" attribute
Is this in the data portion of the module or in a contained procedure of the module?
Can you show the declaration of current_sedc and show the type declaration for current_sedc's type.
Note, if current_sedc is located in the data portion of the module then the SAVE attribute is not warranted. (It would be if in a contained procedure).
The error message implies that current_sedc (at location of offending statement) is a pointer as opposed to an object.
Is current_sedc declared in the scope of the offending statement in addition to within the module used? (iow superseding module's declaration)
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With lots of detail elided, this looks like
module dftd
<other module use statements>
use dftd_utils,only : sedc_calculation
type(sedc_calculation), save :: current_sedc
contains
subroutine sedc_calculate_properties (cell_in)
use dftd_utils,
type(unit_cell), intent(in) :: cell_in
type(sedc_calculation) :: sedc_calc
< compuation code which populates "sedc_calc" >
current_sedc = sedc_calc ! <====== Abort happens on this line
end subroutine sedc_calculate_properties
end module dftdmodule dftd_utils
!Bunch of constants required for unit conversion......
use constants
implicit none
private
!This is used to store the results of a calculation
type, public :: sedc_calculation
!Scheme name
integer :: Scheme = Not_Assigned
character(len=10) :: schemeStr
!XC functional name
character(len=10) :: xc_functional
!Unit cell info
integer :: num_ions
real(kind=dp) :: real_lattice(3,3)
real(kind=dp) :: recip_lattice(3,3)
real(kind=dp) :: cell_volume
!Periodic table with custom species
integer :: periodic_table_size
character(len=8), allocatable :: periodic_table(:)
!Species info (for cross checking)
integer :: num_species
integer, allocatable :: species_Z(:)
character(len=8), allocatable :: species_symbol(:)
integer, allocatable :: species_base(:)
!Atom information
real(kind=dp), allocatable :: frac_positions(:,:)
real(kind=dp), allocatable :: cart_positions(:,:)
integer, allocatable :: ion_Z(:)
!Some extra info
integer, allocatable :: num_plane_waves_kp(:)
!Results from dispersion methods
real(kind=dp) :: energy
real(kind=dp) :: stress(6)
real(kind=dp), allocatable :: forces(:,:,:)
!Flags to say whether we have these quantities
logical :: have_energy = .false.
logical :: have_forces = .false.
logical :: have_stress = .false.
!Flags to say whether we want these quantities
logical :: need_energy = .false.
logical :: need_forces = .false.
logical :: need_stress = .false.
!Tolerances for convergence of energy,forces,stress
real(kind=dp) :: energy_tol
real(kind=dp) :: forces_tol
real(kind=dp) :: stress_tol
!Terms for TS method
logical :: have_ts_ratios = .false.
logical :: need_ts_ratios = .false.
real(kind=dp), allocatable :: TS_ratios(:)
!Some derivatives for stress
real(kind=dp), dimension(3,3) :: volume_deriv !Derivative of volume WRT lattice matrix
real(kind=dp), dimension(3,3) :: recip_lattice_deriv !Change in reciprocal lattice matrix WRT real lattice
!Must store the custom param string to check if these have changed
character(len=file_maxpath),dimension(:),allocatable ::sedc_custom_params
!Some finite derivative points
integer :: fd_num_steps
real(kind=dp) :: fd_step_size
real(kind=dp), allocatable :: fd_coeffs(:)
!SCS parameters
logical :: have_scs=.false. !Have we saved the scs parameters already?
real(kind=dp), allocatable :: scs_c6(:) !scs c6 parameters (per ion)
real(kind=dp), allocatable :: scs_r0(:) !scs r0 parameters (per ion)
real(kind=dp), allocatable :: scs_alpha(:) !scs alpha parameters (per ion)
!MBD Range parameters
logical :: mbd_range_custom ! Custom range parameters
real(kind=dp) :: mbd_pair_range ! Maximum pairwise interaction distance
real(kind=dp) :: mbd_tensor_range ! Maximum range for coupled VdW modes
!Verbosity level
integer :: iprint
!Debug output devel flag
logical :: debug_output
end type sedc_calculation
contains
<routenes elided>
end module dftd_utils
@krefson wrote:
I am encountering a mysterious diagnostic forrtl: severe (122): invalid attempt to assign into a pointer that is not associated. in a rather large Fortran code on which I develop. It is mysterious because no pointers are involved. The abort line from the traceback is 656 current_sedc = sedc_calc where "current_sedc" and "sedc_calc" are instances of a straightforward derived type containing small arrays and allocatable arrays of intrinsic types, logical, real, integer and character. No pointers, derived type components, classes, parameterization or anything fancy. current_sedc is a module-level declaration with the "save" attribute, and "sedc_calc" is a subroutine-scope declaration in the same scope as the assignment statement. This error only occurs with very recent versions of both ifort and ifx, 2021.7.0 and 2021.7.1 (in oneAPI releases 2022.2.0 and 2022.2.1), and no abort was seen in any earlier version. It occurs at all optimization and debug levels. Furthermore it does not occur with any of the other four different Fortran compilers I have tried. Therefore I suspect a compiler bug. It's a very large code, and unfortunately my attempts to boil down to a reproducible test case have failed. The only other diagnostic I have been able to obtain is a valgrind trace ==3441== Conditional jump or move depends on uninitialised value(s) ==3441== at 0x588A8CF: do_alloc_assign (in ) ... ==3441== Use of uninitialised value of size 8 ==3441== at 0x588A938: do_alloc_assign (in ) ... ==3441== Invalid read of size 8 ==3441== at 0x588A938: do_alloc_assign (in ) all at the call site reported by the diagnostic. By contrast, if I compile using 2022.1.0 and run under valgrind the run completes with no such diagnostics. Any suggestions of how to proceed will be welcome. As I wrote above, the failure occurs only in the context of the whole program, and my efforts to encapsulate the offending code in a smaller example do not reproduce the issue. Keith Refson
> The error message implies that current_sedc (at location of offending statement) is a pointer as opposed to an object.
The error message is clearly wrong.
Hope this clarifies.
K.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I made a test program from your code above. A few edits were necessary to get it to compile. This program compiles and runs OK using oneAPI ifort, and oneAPI ifx version 2022.1.0.256 x64 build Debug and Release configuration.
! krefson.f90
module constants
integer, parameter :: dp = SELECTED_REAL_KIND(13)
integer, parameter :: file_maxpath = 512
integer, parameter :: Not_Assigned = Z'80000000' ! a.k.a. -0
end module constants
module dftd_utils
!Bunch of constants required for unit conversion......
use constants
implicit none
private
type, public :: unit_cell
real(kind=dp) :: mass
end type unit_cell
!This is used to store the results of a calculation
type, public :: sedc_calculation
!Scheme name
integer :: Scheme = Not_Assigned
character(len=10) :: schemeStr
!XC functional name
character(len=10) :: xc_functional
!Unit cell info
integer :: num_ions
real(kind=dp) :: real_lattice(3,3)
real(kind=dp) :: recip_lattice(3,3)
real(kind=dp) :: cell_volume
!Periodic table with custom species
integer :: periodic_table_size
character(len=8), allocatable :: periodic_table(:)
!Species info (for cross checking)
integer :: num_species
integer, allocatable :: species_Z(:)
character(len=8), allocatable :: species_symbol(:)
integer, allocatable :: species_base(:)
!Atom information
real(kind=dp), allocatable :: frac_positions(:,:)
real(kind=dp), allocatable :: cart_positions(:,:)
integer, allocatable :: ion_Z(:)
!Some extra info
integer, allocatable :: num_plane_waves_kp(:)
!Results from dispersion methods
real(kind=dp) :: energy
real(kind=dp) :: stress(6)
real(kind=dp), allocatable :: forces(:,:,:)
!Flags to say whether we have these quantities
logical :: have_energy = .false.
logical :: have_forces = .false.
logical :: have_stress = .false.
!Flags to say whether we want these quantities
logical :: need_energy = .false.
logical :: need_forces = .false.
logical :: need_stress = .false.
!Tolerances for convergence of energy,forces,stress
real(kind=dp) :: energy_tol
real(kind=dp) :: forces_tol
real(kind=dp) :: stress_tol
!Terms for TS method
logical :: have_ts_ratios = .false.
logical :: need_ts_ratios = .false.
real(kind=dp), allocatable :: TS_ratios(:)
!Some derivatives for stress
real(kind=dp), dimension(3,3) :: volume_deriv !Derivative of volume WRT lattice matrix
real(kind=dp), dimension(3,3) :: recip_lattice_deriv !Change in reciprocal lattice matrix WRT real lattice
!Must store the custom param string to check if these have changed
character(len=file_maxpath),dimension(:),allocatable ::sedc_custom_params
!Some finite derivative points
integer :: fd_num_steps
real(kind=dp) :: fd_step_size
real(kind=dp), allocatable :: fd_coeffs(:)
!SCS parameters
logical :: have_scs=.false. !Have we saved the scs parameters already?
real(kind=dp), allocatable :: scs_c6(:) !scs c6 parameters (per ion)
real(kind=dp), allocatable :: scs_r0(:) !scs r0 parameters (per ion)
real(kind=dp), allocatable :: scs_alpha(:) !scs alpha parameters (per ion)
!MBD Range parameters
logical :: mbd_range_custom ! Custom range parameters
real(kind=dp) :: mbd_pair_range ! Maximum pairwise interaction distance
real(kind=dp) :: mbd_tensor_range ! Maximum range for coupled VdW modes
!Verbosity level
integer :: iprint
!Debug output devel flag
logical :: debug_output
end type sedc_calculation
contains
! <routenes elided>
end module dftd_utils
module dftd
! <other module use statements>
use dftd_utils,only : sedc_calculation
type(sedc_calculation), save :: current_sedc
contains
subroutine sedc_calculate_properties (cell_in)
use dftd_utils
type(unit_cell), intent(in) :: cell_in
type(sedc_calculation) :: sedc_calc
! < compuation code which populates "sedc_calc" >
current_sedc = sedc_calc ! <====== Abort happens on this line
print *,"ok"
end subroutine sedc_calculate_properties
end module dftd
program krefson
use dftd_utils
use dftd
implicit none
type(unit_cell) :: cell
call sedc_calculate_properties (cell)
print *,"done"
end program krefson
Can you see if this "reproducer" fails on your system.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your test program succeeds on my system, as I anticipated - my own attempt at extracting a reproducible case did allocate most of the arrays in the type too.
By the way, your test system 2022.1.0 would have succeed even for the full program, as that is not the version which fails. The failure occurs only with 2022.2.0 and 2022.2.1.
K.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have not installed 2022.2.0 nor 2022.2.1 as the improvements for ifort/ifx were not significant (as they were for C++).
With 2023 weeks away, I will await until then to update.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Now that 2023.0.0 has arrived, I have it a spin with the latest version, and the test run completes successfully.
I will update the compile notes for our users to avoid the 2022.2 versions of ifort as buggy.
K.
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