- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello all.
I am trying to compile some code that works with Intel Fortran v.14 in Windows, but this time with Intel Fortran v.15 in Linux. I have got an allocation error (forrtl: severe (151): allocatable array is already allocated) at a certain function line with an allocation. If I am not wrong the runtime error occurs the second time the function is called. Apparently the issue is solved by adding a deallocation previously. It is extrange for me as I expected a local scope behavior for that variable, declared inside the function.
Does it make sense? Different behaviour in something like this for different platforms? Note: I am not experienced in Linux. Maybe I missed something.
Thanks and regards.
PD: Piece of the code:
function laminate_constructor_simple(material, stack, name)
...
type(Lamina), dimension(:), allocatable :: materials
...
if (allocated(materials)) deallocate(materials) ! added to work with Linux RHEL Intel Fortran !
allocate(materials(1)) ! line giving the error in Linux, working fine in Windows
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is no difference in platforms here. What compile options are you using on each platform? Using -save (/Qsave) by any chance?
I notice in the fragment you posted that the dummy argument is named material but the declaration calls it materials. These would be different. Of course, you might have freehand typed it in and made an error - all the more reason to provide us with a complete example that shows the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Steve.
Yes, materials and material are different variables, the first is an array, the second an scalar. That is under control :)
I attach now a reduced example with a similar structure to my code giving the same error when I compile and run in Linux, but it still works in Windows...
module module_test public function_test contains function function_test() real :: function_test integer, dimension(:), allocatable :: array allocate(array(1)) end function end module program test use module_test real :: a, b a = function_test() b = function_test() pause end program
Regarding the compilation parameters, in Linux, I have just added the parameters to trace the error line (I still dont't have an IDE for Linux):
ifort -o test_alloc_dealloc.exe -g -traceback test_alloc_dealloc.f90
PD. Error in Linux: ./test_alloc_dealloc.exe
forrtl: severe (151): allocatable array is already allocated Image PC Routine Line Source test_alloc_deallo 00000000004082D7 Unknown Unknown Unknown test_alloc_deallo 0000000000402FD1 MAIN__ 9 test_alloc_dealloc.f90 test_alloc_deallo 0000000000402E8E Unknown Unknown Unknown libc.so.6 0000003B5301ED1D Unknown Unknown Unknown test_alloc_deallo 0000000000402D99 Unknown Unknown Unknown
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Which compiler version are you using on the two systems? Show the output of "ifort -V". I can't reproduce this using 16.0.2 on Linux.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
On the older versions of Fortran the locally declared arrays are implicitly SAVE. You can override this with option /auto, or /Qopenmp, or /recursive, or "recursive function function_test()".
The newer releases of Fortran default to /recursive
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Jim, I'll try with those compilation parameters...
Steve,
On Linux I have, after ifort -V..
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.3.187 Build 20150407 Copyright (C) 1985-2015 Intel Corporation. All rights reserved. GNU ld version 2.20.51.0.2-5.36.el6 20100205 /opt_cluster/intel_2015/composer_xe_2015.3.187/compiler/lib/intel64/for_main.o: In function `main': for_main.c:(.text+0x2a): undefined reference to `MAIN__'
On Windows I have...
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Inte l(R) 64, Version 14.0.5.239 Build 20150212 Copyright (C) 1985-2014 Intel Corporation. All rights reserved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's not the case, Jim. Local allocatable arrays have never been SAVE by default, but use of -save does make them so. There might be a compiler bug that prevents the automatic deallocation, something that came into being with Fortran 95.
I am also a bit suspicious in that the traceback line number doesn't match the code that was posted.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Steve.
My fault, I missed a couple of blank lines when copy/paste. When splitting that code in module and program files I got this:
forrtl: severe (151): allocatable array is already allocated Image PC Routine Line Source test_alloc_deallo 00000000004081C7 Unknown Unknown Unknown test_alloc_deallo 0000000000402F40 module_test_mp_fu 7 module_test.f90 test_alloc_deallo 0000000000402F75 MAIN__ 5 test_alloc_dealloc.f90 test_alloc_deallo 0000000000402E8E Unknown Unknown Unknown libc.so.6 0000003B5301ED1D Unknown Unknown Unknown test_alloc_deallo 0000000000402D99 Unknown Unknown Unknown
Complete module file is this:
module module_test public function_test contains function function_test() real :: function_test integer, dimension(:), allocatable :: array allocate(array(1)) end function end module
Complete program file is this:
program test use module_test real :: a, b a = function_test() b = function_test() pause end program
Let's see if this time is properly numbered...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok. I see you have two very different versions of the compiler, neither of them current. But I can't reproduce with that version either.
Please show a complete session on Linux where you compile, link and run the sources with -V added to the ifort commands.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please also show the output of "ifort -watch -c" on one of the sources.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this the info?
ifort -o test_alloc_dealloc.exe -g -traceback -V module_test.f90 test_alloc_dealloc.f90 Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.3.187 Build 20150407 Copyright (C) 1985-2015 Intel Corporation. All rights reserved. Intel(R) Fortran 15.0-1812 module_test.f90(4): warning #6178: The return value of this FUNCTION has not been defined. [FUNCTION_TEST] function function_test() -----------------^ Intel(R) Fortran 15.0-1812 GNU ld version 2.20.51.0.2-5.36.el6 20100205
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With -watch -c ...
ifort -watch -c test_alloc_dealloc.f90 echo test_alloc_dealloc.f90 test_alloc_dealloc.f90 /opt_cluster/intel_2015/composer_xe_2015.3.187/bin/intel64/fortcom \ -D__INTEL_COMPILER=1500 \ -D__INTEL_COMPILER_UPDATE=3 \ -D__unix__ \ -D__unix \ -D__linux__ \ -D__linux \ -D__gnu_linux__ \ -Dunix \ -Dlinux \ -D__ELF__ \ -D__x86_64 \ -D__x86_64__ \ -D__amd64 \ -D__amd64__ \ -D_MT \ -D__INTEL_COMPILER_BUILD_DATE=20150407 \ -D__INTEL_OFFLOAD \ -D__pentium4 \ -D__pentium4__ \ -D__tune_pentium4__ \ -D__SSE2__ \ -D__SSE2_MATH__ \ -D__SSE3__ \ -D__SSSE3__ \ -D__SSE4_1__ \ -D__SSE4_2__ \ -D__SSE__ \ -D__SSE_MATH__ \ -D__MMX__ \ -D__AVX__ \ -mGLOB_pack_sort_init_list \ -I. \ -I/opt_cluster/intel_2015/composer_xe_2015.3.187/ipp/include \ -I/opt_cluster/intel_2015/composer_xe_2015.3.187/mkl/include \ -I/opt_cluster/intel_2015/composer_xe_2015.3.187/tbb/include \ -I/opt_cluster/intel_2015/composer_xe_2015.3.187/compiler/include/intel64 \ -I/opt_cluster/intel_2015/composer_xe_2015.3.187/compiler/include \ -I/usr/local/include \ -I/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include \ -I/usr/include/ \ -I/usr/include \ "-assume protect_parens" \ "-assume minus0" \ "-assume byterecl" \ -noautomatic \ "-convert big_endian" \ "-fp_model source" \ -O3 \ -simd \ -offload_host \ -mP1OPT_version=15.0-intel64 \ -mGLOB_diag_file=test_alloc_dealloc.diag \ -mGLOB_source_language=GLOB_SOURCE_LANGUAGE_F90 \ -mP2OPT_static_promotion \ -mP1OPT_print_version=FALSE \ -mCG_use_gas_got_workaround=F \ -mP2OPT_align_option_used=TRUE \ -mGLOB_gcc_version=447 \ "-mGLOB_options_string=-save -axCORE-AVX2 -mavx -fp-model source -assume minus0 -O3 -convert big_endian -assume byterecl -lpthread -watch -c" \ -mGLOB_cxx_limited_range=FALSE \ -mCG_extend_parms=FALSE \ -mGLOB_compiler_bin_directory=/opt_cluster/intel_2015/composer_xe_2015.3.187/bin/intel64 \ -mGLOB_as_output_backup_file_name=/tmp/ifortH7JpgYas_.s \ -mIPOPT_activate \ -mIPOPT_lite \ -mGLOB_em64t \ -mGLOB_instruction_tuning=0x0 \ -mGLOB_product_id_code=0x22006d8f \ -mCG_bnl_movbe=T \ -mGLOB_extended_instructions=0x800 \ -mGLOB_specialized_instructions=0x4000 \ -mIPOPT_auto_cpu_activate \ -mP3OPT_use_mspp_call_convention \ -mP2OPT_subs_out_of_bound=FALSE \ -mGLOB_ansi_alias \ -mPGOPTI_value_profile_use=T \ -mP2OPT_il0_array_sections=TRUE \ -mGLOB_offload_mode=1 \ -mP2OPT_offload_unique_var_string=ifort010793688086ybf3ob \ -mGLOB_opt_level=3 \ -mP2OPT_hlo_level=3 \ -mP2OPT_hlo \ -mP2OPT_hpo_rtt_control=0 \ -mIPOPT_args_in_regs=0 \ -mP2OPT_disam_assume_nonstd_intent_in=FALSE \ -mGLOB_imf_mapping_library=/opt_cluster/intel_2015/composer_xe_2015.3.187/bin/intel64/libiml_attr.so \ -mPGOPTI_gen_threadsafe_level=0 \ -mIPOPT_obj_output_file_name=test_alloc_dealloc.o \ -mIPOPT_whole_archive_fixup_file_name=/tmp/ifortwarchNWqQ7k \ -mGLOB_linker_version=2.20.51.0.2 \ -mGLOB_long_size_64 \ -mGLOB_routine_pointer_size_64 \ -mGLOB_driver_tempfile_name=/tmp/iforttempfilemIeKy1 \ -mP3OPT_asm_target=P3OPT_ASM_TARGET_GAS \ -mGLOB_async_unwind_tables=TRUE \ -mGLOB_obj_output_file=test_alloc_dealloc.o \ -mGLOB_source_dialect=GLOB_SOURCE_DIALECT_FORTRAN \ -mP1OPT_source_file_name=test_alloc_dealloc.f90 \ -mP2OPT_symtab_type_copy=true \ test_alloc_dealloc.f90 rm /tmp/ifortdummyThyYMR.c rm /tmp/ifortdashvuY1Uay rm /tmp/ifortlibgcc9WEiAe rm /tmp/ifortgnudirsSBQ1ZU rm /tmp/ifortgasyoiTPh rm /tmp/ifortH7JpgYas_.s rm /tmp/ifortldashvOB1WGE rm /tmp/iforttempfilemIeKy1 rm /tmp/ifortargjGkGZH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hah! -noautomatic! My guess is that you have an ifort.cfg file that adds -save, in addition to some other options. This supplies additional options added to every compile.
Either specify -auto on your command line or edit the ifort.cfg file to remove -save. It might be spelled -noauto instead.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's it! Thanks! I will check with our system administration if there was any specific reason to set that flag by default.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page