Hi:

   sorry for the disturbing.

   Now I compile all my ocean model with the help of ifort, but I also need to use the NCL static lib which compiled by gfortran. it always said that "undefined reference to MAIN__"

   What should I do now? Thanks for your help.

Best Regards

My dear friend:

my new version compiler is ifort version 19.0.2.187

system is linux(redhat)

my compiler is following:

ifort -c head_sublibf.f90 -std03 -fPIC -assume nounderscore -assume bscc -assume byterecl -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fpp

my code Complier and link is ok ,but run my code ,when it call the subroutinue is core .

If optional no default, i have it trc = 1 and channel = 0, my code runing is ok!

please help me ,thank!

following is part code :

!   my module:head_sublibf.f90      hdd_get is polymorphism  interface

   MODULE head_sublibf

    interface

    integer( c_int ) function hdd_seti_by_name(name,head_buffer,result,trc,channel )  bind( C )

    use, intrinsic::ISO_C_BINDING

    implicit none

    character (len = *) ::name

    integer(C_INT), dimension(*)::head_buffer

    integer (C_INT):: result

    integer (C_INT),OPTIONAL:: trc

    integer (C_INT),OPTIONAL:: channel

    end function hdd_seti_by_name

   end interface

    INTERFACE hdd_get

      MODULE PROCEDURE fhddgeti_byname

      MODULE PROCEDURE fhddgetl_byname

      MODULE PROCEDURE fhddgetf_byname

      MODULE PROCEDURE fhddgetd_byname

    END INTERFACE

      integer(C_INT) FUNCTION fhddgeti_byname( name,head_buffer,result,trc,channel )

      use,intrinsic::ISO_C_BINDING

      implicit none

        character (len = *) ::name

        integer(C_INT), dimension(*)::head_buffer

        integer (C_INT):: result

        integer (C_INT),OPTIONAL:: trc

        integer (C_INT),OPTIONAL:: channel

        integer (C_INT)::trc_default

        integer (C_INT)::channel_default

        write(*,*) "--------- fhddgeti :",name

        write(*,*) "trc:",trc

        write(*,*) "channel: ",channel

        if(present(trc) ) then

           trc_default =trc

        else

!           write(*,*) " default parameter --- trc"

           trc_default =1

        endif

        if(present(channel)) then

           channel_default =channel        

        else

!           write(*,*) " default parameter --- channel"

           channel_default =0

        endif

!        write(*,*) "--------- fhddgeti - name :",no   

!        write(*,*) "--------- fhddgeti - trc:",trc_default

!        write(*,*) "--------- fhddgeti - channel:",channel_default

        fhddgeti_byname = hdd_geti_by_name(name,head_buffer,result,trc_default,channel_default)

      END FUNCTION

   ............

    END MODULE

following is program.  it call module (head_sublibf.f90)

 1         dytest1 = hdd_get("max_samples",head,iresult,1,0)

 2         write(*,*) "AM---name parameter samples-------n :",dytest1, iresult

 3         dytest = hdd_get("max_samples",head,iresult)

 4         write(*,*) "AM---name parameter samples --- name:",dytest, iresult

code Line Numbers 1  optional parameter is 1,0 .i give it .the subroutine call is right. Line Numbers 2 give right resulte.

code Line Numbers 3  the optional parameter i use default value. (default is 1,0). the subroutine call is core.

i don't know why？

please tell me 。 where is wrong ？ thanks！

Dear all

First of all I must apologize as I for legal reasons can't show any actual code and I have not been able to draft dummy code that can reproduce the problem I am experiencing. The code in question is doing scientific HPC calculations and is of the order of 200 000 lines long. Core parts of it is F77 and my job is to update the code and turn everything into more modern Fortran. Serial performance is a very high priority as we are pushing the limits when it comes to parallelization at a few thousands cores. The core subroutines (serial, all parallelization is done at a higher level) are hit billions of times and the code in those subroutines are optimized for vectorization. I can, again for legal reasons, not copy any output or code from the system where the code is running, but I hope you all can see beyond any obvious typos.

The code used to run without any problems but after  an update of parts not related(?) to the core routines I am getting error(65), Floating invalids right of the bat in one of the core subroutines. It is obviously something I have done but I can for my life not figure it out and the problem turned out to be very difficult to debug. I only see the error when the compiler vectorize the code. Whatever I do that turn vectorization off (-novec, -O0 or -O1 or add any form of -check for example or fork the code with a print statement in the vectorized part) also "fix" the problem and the code will run without any errors.

The update I did was to change the definition of the local floats in a few supporting subroutines and functions from double precision to selected_real_kind(15,307). All floats in modules are still defined as double precision and the same is true for all local floats in the core routines. The code is compiled with the options " -mcmodel=large -align array64byte -xCORE-AVX512 -O3 -qopt-zmm-usage=low -fp-model fast=2 -g -traceback -qopt-report=5" and that has not been changed. The code will for some reason always crash with -qopt-zmm-usage=high and Intel's experts have not been able to diagnose that problem which of course is of some concern.

The run-time error and Intel Inspector point to a specific line in the code and Inspector also indicates that there is something going partially wrong when a array used in the aforementioned line is allocated. The array in question is defined in a module

double precision, dimension(:), allocatable :: A, B, C

and allocated as

allocate(A(1:nj))

Inspector reports a Invalid partial memory access when the array is allocated. When I add code to inquire the status of the allocation I get STAT=0. The array A is used in the code before the core routine where the code crashes without any problem. The segment of the core subroutine where the code crashes looks like this:

!DIR$ ASSUME_ALIGNED A(1):64
!DIR$ ASSUME_ALIGNED B(1):64
!DIR$ ASSUME_ALIGNED C(1):64

!DIR$ IVDEP

do j = 1, nj

  locarray1(j) = locvar1 + locvar2*B(j)/A(j) + locvar3*C(j)  ! CRASH HERE

end do

All local arrays and variables are defined as double precision and I can inspect A, B and C and all other variables outside of the loop and the bounds are well defined and all values are non-NaN and not zero (A ~ 0.5). Inspector reports Invalid memory access at the offending line.

I have tried to align the arrays A, B, and C "by hand" by using !DIR$ attributes align: 64 :: A, B,C in the module where the arrays are defined without any difference. In the optrpt-file the compiler reports

vectorization support: reference A(j) has aligned acess

and the same for locarray1, B, and C. The loop in question is vectorized without a peel loop but with a small reminder loop.

Sorry for the wall of text and lack of actual code. I hope I could make my case anyway. It is frustrating to debug a code where any attempt to look closer at the problem makes it go away. Could it be that the KIND parameter used in the updated subroutines messes the alignment up in some global context? Is the "new" KIND parameter not compatible with -align array64byte?

Best regards

Per

I have been updating some fortran modeling software for streamflow simulation. Until recently I had primarily used gfortran for compiling the code. Having obtained a license for the Intel compilers on Macos I have started testing my code with ifort.

I have run into a problem with using pointers to dynamically allocated arrays. We have an object which handles the output of summary information from other objects' arrays. For efficiency all the other objects use the summary object to set pointers to the required dynamic arrays within those objects. This happens during the initialization/constructor phase of the program. With gfortran this has worked quite well but with ifort I have been getting segmentation faults. What appears to be happening is the address for a dynamically allocated array is different after returning from an object's constructor compared to what is after allocation within the constructor. Because the summary object's pointer is set during the constructor phase for each object (after an array has been allocated) this is causing all manner of mischief. After a lot of digging I have created what is hopefully a simple, reproducible test case.

I'm not sure if I'm just missing something incorrect in my approach or if this is some bug. When I run the test with gfortran the address for an array stays constant during program execution, however, with ifort the address for an array changes after returning from the constructor. I would appreciate any help/insight you could provide.

-parker

Hello,

Is there a reason why if I compile with both -ipo qopt-report=5, my optrpt report does not contain much of information. While If i removed -ipo I get the information in the report file as I would expect.

I'm using dlopen and dlsym to open a shared library and execute a procedure. It works fine on Windows and Linux, but I see a weird issue on Mac. Consider the following example:

Main code (main.f90):

program main

    use, intrinsic :: iso_c_binding

    implicit none

    procedure(func),pointer :: execute  !! procedure in the shared lib
    integer(c_intptr_t) :: dll_handle
    integer(c_intptr_t) :: procaddress

    integer(c_int),parameter :: rtld_lazy = 1

    abstract interface
        subroutine func(id)
        implicit none
        integer,intent(in) :: id
        end subroutine func
    end interface

    interface
        function dlopen(library, iflag) result(handle) bind(c, name='dlopen')
            import
            implicit none
            integer(c_intptr_t)                             :: handle
            character(kind=c_char),intent(in),dimension(*)  :: library
            integer(kind=c_int),intent(in),value            :: iflag
        end function dlopen
        function dlsym(handle, method) result(funptr) bind(c, name='dlsym')
            import
            implicit none
            integer(c_intptr_t)                             :: funptr
            integer(c_intptr_t),intent(in),value            :: handle
            character(kind=c_char),intent(in),dimension(*)  :: method
        end function dlsym
    end interface

    dll_handle = dlopen('test.so'//c_null_char, rtld_lazy)
    procaddress = dlsym(dll_handle, 'execute'//c_null_char)
    call c_f_procpointer(transfer(procaddress,c_null_funptr), execute)

    call execute(42)

end program main

Shared library code (test.f90):

module test_module

    implicit none

contains

    subroutine execute(id)
    ! -- DEC$ ATTRIBUTES ALIAS : "execute" :: execute ! doesn't work
    !DEC$ ATTRIBUTES ALIAS : "_execute" :: execute ! works

    integer,intent(in) :: id

    write(*,*) '[execute] id = ', id

    end subroutine execute

end module test_module

Built using:

ifort -dynamiclib test.f90 -o test.so
ifort main.f90 -o main

I'm unable to access the procedure as "execute" without prepending an underscore to the DEC ALIAS command. This is not necessary on Windows or Linux. Is there some DEC magic that will allow me not to have to add this? Is this a bug in the Mac compiler?

Note that I think bind(c) also makes it work, but I can't use that for my real code since the procedure contains non-interoperable arguments.

Revisiting an old topic, would it be possible to add a slightly different option to the "truncated_source" -warn flag that ignores comment fields?  We encourage our developers to heavily comment their code, but with "-warn truncated_source" set, there are a lot of false positives when comments that start with the "!" symbol run past 132 columns.

Thanks for considering.

We have a science model that simulates an agricultural field for susceptibility to wind erosion.  The current version assumes the entire field consists of the same soil and that the entire field is treated with the same mgt practices.  We have developed a new version that allows the user to specify multiple soil types and mgt practices for the field.  Thus, rather than a single "subregion" (one soil and one set of mgt practices), we can now represent the field with multiple subregions, e.g. multiple soils and mgt practices.  Of course, the code takes significantly longer to run when multiple subregions are being simulated when compiled and run serially.  As a first step in trying to parallelize this code, we attempted to simulate each individual subregions' calculations on separate threads, or at least that is what we thought we were attempting (we have never done any parallelization of Fortran code before).  Here is a brief description of what we have done to parallelize the do loop that steps through each subregion on a daily basis in the model:

         do am0jd = ijday,lcaljday !step through each day of the simulation

            […]

           !$omp parallel do

           do isr=1,nsubr   ! do multiple subregions' daily simulations    

             call submodels(isr, soil(isr), plants(isr)%plant, plants(isr)%plantIndex, restot(isr), croptot(isr), &

                 biotot(isr), decompfac(isr), mandatbs(isr)%mandate, hstate(isr), h1et(isr), h1bal(isr), wp(isr), manFile(isr))

             […]

           end do

           !$omp end parallel do

           […]

         end do

As I understand, the "isr" variable is automatically private and all (or most?) other variables are shared by default, so we don't (shouldn't) need to state that explicitly in the directive.  The test case we are running contains four subregions. There are a couple of issues we've discovered when running the code (sorry that I don't have the actual wallclock runtimes, but I don't think they are necessary at this point to answer my initial questions):

1. When run serially, e.g. without the openmp compiler option, with "-O3" we get the expected run time compared to our single subregion code with the same optimization level.
2. When we run serially without the no optimization, we get much slower runtime, as expected.
3. When run with the openmp compiler option, with our without the "-O3" option, we get much slower runtimes, on the order of 10 times slower than when the code was compiled with the "-O3" option alone, e.g. much closer to the results we get when compiling with no optimization at all.
4. Since we saw no speedup, we wanted to see if we were actually getting additional threads active for the openmp compiled code, so we ran "nmon" on our Ubuntu 18.04 system to "see" the activity level of all 8 threads (the CPU is a "Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz", e.g. 4 physical cores with hyperthreading with 8 total threads available.
   1. If we run the code compiled without the openmp cmdline option, we would see one thread hit 100% utilization, as expected.
   2. If we ran the code compiled with the openmp option, we would see all threads becoming active.
   3. If I set the thread limit to 4, we would see only 4 threads active at one time, but not necessarily the same ones.
   4. In some runs, we would generate a warning msg that we were trying to deallocate arrays that had previously been deallocated. The more threads that were active, the higher the chance was that we would encounter these messages.

Here is what we think we have learned:

• We are getting additional threads active when compiled with the openmp option.
• We were not getting the individual threads to run the entire sequence of calculations serially for a single subregion (loop index variable) as we originally anticipated. This was essentially confirmed from the deallocate messages as they could only occur from the running code with the same loop index variable (same subregion code).
• Since we are setting up the parallel do construct for each day of the simulation and tearing it down, it is now obvious to us that we probably can make some coding changes to eliminate a lot of this recurring overhead and do a much better job of parallelizing this part of the code.  So, we have this task to to address in the future, once we get this step in the code to be parallelized correctly.
• We are not sure if the optimization options are having any effect or not when used in conjunction with the openmp option.  We saw no noticeable (significant) differences in runtimes, but figured we needed to get the subregion code to run as desired when parallelized first before looking into this potential issue.

So, the fundamental question here is what do we need to do to get the individual subregions' code to run in parallel for all four subregions simultaneously on separate threads, but to run each individual subregion's instance serially on each of those threads?  I am assuming we need to add additional OMP directives to keep the additional auto-parallelization from occurring in the code, but which directive(s) with what args and where in the code?

Thanks,

LEW

There appears to be a seg fault regression introduced in Intel 2019 Fortran compiler, consider the code:

module testmod
use iso_c_binding
integer, parameter, public :: f_int = c_int64_t
type, bind(c), public :: NextValMType
 integer(f_int) :: ga_handle
end type NextValMType

contains
  function nextvalm_init(n_counter) bind(c)
    type(NextValMType) :: nextvalm_init
    integer(f_int), intent(in), value :: n_counter
    write(6,*)'n_counter=',n_counter
    nextvalm_init%ga_handle=n_counter
  end function
end module

program test
use testmod
type(NextValMType) :: nvm
integer :: i=5
write(6,*)'i=',i
nvm=nextvalm_init(i)
end

This works as expected with gfortran, Intel 2017 and 2018, but not 2019:

> module purge && module load gcc/9.1.0 && gfortran -fdefault-integer-8 intel2019_bug.f90 && ./a.out                  
 i=                    5
 n_counter=                    5                              
> module purge && module load intel/2017.5.239 && ifort -i8 intel2019_bug.f90 && ./a.out                  
 i=                     5         
 n_counter=                     5
> module purge && module load intel/2018.3.222 && ifort -i8 intel2019_bug.f90 && ./a.out                  
 i=                     5                        
 n_counter=                     5
> module purge && module load intel/2019.1.144 && ifort -i8 intel2019_bug.f90 && ./a.out                  
 i=                     5
 n_counter=                     0
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
a.out              00000000004047C3  Unknown               Unknown  Unknown
libpthread-2.19.s  00007F0B23920870  Unknown               Unknown  Unknown
a.out              00000000004038B7  Unknown               Unknown  Unknown
a.out              00000000004037A2  Unknown               Unknown  Unknown
libc-2.19.so       00007F0B2358AB25  __libc_start_main     Unknown  Unknown
a.out              00000000004036A9  Unknown               Unknown  Unknown

The latest version I have available is 19.0.1.144. Is this a known problem and has it been fixed in subsequent updates?

Many thanks

I am trying to do an install on a new computer using an existing license server of the Intel 18 Fortran Compiler.  Based on the content of the intel.lic file, how can I determine which intel package to download.  I've already tried 2 :/

Tony

In Windows, I have long used iFort's simple compiler directive facility for conditional compilation.

https://software.intel.com/en-us/fortran-compiler-developer-guide-and-re...

for example

!DIR$ IF(FOO==1)

do something

!DIR$ ELSE

do something else

!DIR$ ENDIF

In Windows Developer Studio the value of FOO can be set globally in the project properties page in

Configuration Properties > Fortran > Preprocessor > Preprocessor Definitions

in the form FOO=1;FIE=0;FUM=1 ... etc.

These definitions are then applied to all files in the project. Note that this does not require the "Preprocess Source File" property to be Yes.

I am now trying to get this to work in Linux where I am running Code:Blocks for Fortran (CBFortran) as the IDE. CBFortran offers a project build options page with many of the compiler options, but no "Preprocessor Definitions" line.  I would appreciate some guidance on how to use Intel's Compiler Directives feature in this context.

....

MacOS: High Sierra; Xcode: 10.1 ; Ifort: 18.0.5

Hi,

I have an issue building an application with intel18 on MacOS, which I do not have with gcc,

I have symbols defined in a module io, which are found by the compiler, but not from the linker.

Subroutine set_runtime_parameters()  ! ======> in headers.a

…

      use io,only:amr_log_file,output_dir

                 …

io.F90 is part of a headers.a library, which is passed to the linker, see below. Looking for a workaround, I copied the module files to the directory where the library headers.a is located, but it did not help. Do I miss a flag or something else? Any help is highly appreciated.

Thanks,

Ted

/opt/mpich321_intel18/bin/mpif90    -g -cpp  -O0  -check bounds -check format -zero  CMakeFiles/plotting.bin.dir/__/test_plotting.F90.o 

-o /Users/tesari/lynx/build/intel18_mpich321/ep /bin/plotting.bin

-L/Users/tesari/lynx/build/intel18_mpich321/ep /lib -lheaders                                  ! <==============

/opt/intel/compilers_and_libraries_2018.5.231/mac/compiler/lib/libirng.a

/opt/intel/compilers_and_libraries_2018.5.231/mac/compiler/lib/libdecimal.a -lc++

Undefined symbols for architecture x86_64:

  "_io_mp_amr_log_file_", referenced from:

      _amr_set_runtime_parameters_ in libparamesh.a(amr_set_runtime_parameters.F90.o)

  "_io_mp_output_dir_", referenced from:

      _amr_set_runtime_parameters_ in libparamesh.a(amr_set_runtime_parameters.F90.o)

ld: symbol(s) not found for architecture x86_64

Dear intel,

It seems you have a serious bug in your collapse openmp statements.

I did this small code:

module fail_m
  implicit none

contains
  
  subroutine zero(n, Dk)
    integer :: n
    real :: Dk(2,n,n)

    integer :: i, j

!$OMP parallel do default(shared), collapse(2), private(i,j)
    do j = 1, n
      do i = 1, n
        Dk(1,i,j) = 0.
        Dk(2,i,j) = 0.
      end do
    end do
!$OMP end parallel do
  end subroutine zero

end module fail_m

program test
  use fail_m
  integer, parameter :: n = 200
  real :: Dk(2,n,n)

  call random_number(Dk)
  call zero(n, Dk)

  print '(f10.4)', sum(Dk)
end program test
  

and ran for multiple different versions.

In all cases the program should print out 0.0000. However, for all 2019.X versions it prints something else.

Here is a complete list of the versions I have tested (and whether they failed or succeeded).

Running intel
Success: 2013.0.028
Success: 2013.1.039
Success: 2013.1.046
Success: 2015.0.090
Success: 2015.1.133
Success: 2015.3.187
Success: 2016.1.0.423501
Success: 2016.2.0
Success: 2017.0.035
Success: 2017.1.043
Success: 2017.4.196
Success: 2017.7.065
Success: 2018.0.033
Success: 2018.1.038
Success: 2018.2.046
Success: 2018.3.051
Failed: 2019.0.117 = 29939.7344
Failed: 2019.1.144 = 29939.7344
Failed: 2019.2.187 = 29939.7344
Failed: 2019.3.199 = 29939.7344
 

I need not say how severe this is :(

/ Nick

Can anyone help me trouble-shot?  My understanding was that I only needed ifort since it works with gcc, etc. 
Configure seems to find everything necessary, but during make, it has trouble with "cfortran.h" - which confuses me. 
I can easily make with gcc/gfortran, but my calling program will be compiled with ifort, so I need to build NetCDF with ifort.
(I was able to build OpenMPI3 with ifort/gcc.)

linux-68t00:/usr/local/netcdf-3.6.3 # gcc --version
gcc (SUSE Linux) 6.4.1 20180626 [gcc-6-branch revision 262132]
Copyright (C) 2017 Free Software Foundation, Inc.

linux-68t00:/usr/local/netcdf-3.6.3 # export F90=/home/patti/intel/bin/ifort
linux-68t00:/usr/local/netcdf-3.6.3 # export F77=/home/patti/intel/bin/ifort
linux-68t00:/usr/local/netcdf-3.6.3 # export FC=/home/patti/intel/bin/ifort
linux-68t00:/usr/local/netcdf-3.6.3 # ./configure --prefix /usr/local/netcdf363-ifort

configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
configure: netCDF 3.6.3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
configure: checking user options
checking whether CXX is set to ''... no
checking whether FC is set to ''... no
checking whether F90 is set to ''... no
checking whether this is a netCDF-4.x build... no
checking whether netCDF extra tests should be run (developers only)... no
checking whether documentation is to be installed... no
checking whether Fortran compiler(s) should be tested during configure... yes
checking whether configure should try to set compiler flags... yes
checking whether FFIO will be used... no
checking whether to skip C++, F77, or F90 APIs if compiler is broken... yes
checking whether only the C library is desired... no
checking whether examples should be built... yes
checking whether F77 API is desired... yes
checking whether F90 API is desired... yes
checking whether fortran type sizes should be checked... yes
checking whether C API is desired... yes
checking where to get netCDF C-only library for separate fortran libraries... 
checking whether CXX API is desired... yes
checking whether v2 netCDF API should be built... yes
checking whether the ncgen/ncdump should be built... yes
checking whether large file (> 2GB) tests should be run... no
checking whether benchmaks should be run (experimental)... no
checking whether extreme numbers should be used in tests... yes
checking where to put large temp files if large file tests are run... .
checking whether a win32 DLL is desired... no
checking whether separate fortran libs are desired... no
configure: finding C compiler
checking for xlc... no
checking for cc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of cc... gcc3
checking whether cc understands -c and -o together... yes
checking for an ANSI C-conforming const... yes
configure: finding Fortran compiler (will not be used if Fortran API is not desired)
checking whether we are using the GNU Fortran compiler... no
checking whether /home/patti/intel/bin/ifort accepts -g... yes
checking whether we are using the GNU Fortran 77 compiler... no
checking whether /home/patti/intel/bin/ifort accepts -g... yes
configure: setting up Fortran 90
checking for Fortran flag to compile .f90 files... none
checking fortran 90 modules inclusion flag... -I
checking if Fortran compiler can handle Fortran-90... yes
configure: finding C++ compiler (will not be used if C++ API is not desired)
checking for cl... no
checking for KCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for xlC... no
checking for aCC... no
checking for c++... c++
checking whether we are using the GNU C++ compiler... yes
checking whether c++ accepts -g... yes
checking dependency style of c++... gcc3
configure: setting up libtool
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by cc... /usr/x86_64-suse-linux/bin/ld
checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/x86_64-suse-linux/bin/ld option to reload object files... -r
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from cc object... ok
checking how to run the C preprocessor... cc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether c++ accepts -g... (cached) yes
checking dependency style of c++... (cached) gcc3
checking how to run the C++ preprocessor... c++ -E
checking whether we are using the GNU Fortran 77 compiler... (cached) no
checking whether /home/patti/intel/bin/ifort accepts -g... (cached) yes
checking whether we are using the GNU Fortran compiler... (cached) no
checking whether /home/patti/intel/bin/ifort accepts -g... (cached) yes
checking for objdir... .libs
checking if cc supports -fno-rtti -fno-exceptions... no
checking for cc option to produce PIC... -fPIC -DPIC
checking if cc PIC flag -fPIC -DPIC works... yes
checking if cc static flag -static works... no
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.o... (cached) yes
checking whether the cc linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for ld used by c++... /usr/x86_64-suse-linux/bin/ld -m elf_x86_64
checking if the linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the c++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for c++ option to produce PIC... -fPIC -DPIC
checking if c++ PIC flag -fPIC -DPIC works... yes
checking if c++ static flag -static works... no
checking if c++ supports -c -o file.o... yes
checking if c++ supports -c -o file.o... (cached) yes
checking whether the c++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for /home/patti/intel/bin/ifort option to produce PIC... -KPIC
checking if /home/patti/intel/bin/ifort PIC flag -KPIC works... no
checking if /home/patti/intel/bin/ifort static flag -static works... no
checking if /home/patti/intel/bin/ifort supports -c -o file.o... yes
checking if /home/patti/intel/bin/ifort supports -c -o file.o... (cached) yes
checking whether the /home/patti/intel/bin/ifort linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for /home/patti/intel/bin/ifort option to produce PIC... -KPIC
checking if /home/patti/intel/bin/ifort PIC flag -KPIC works... no
checking if /home/patti/intel/bin/ifort static flag -static works... no
checking if /home/patti/intel/bin/ifort supports -c -o file.o... yes
checking if /home/patti/intel/bin/ifort supports -c -o file.o... (cached) yes
checking whether the /home/patti/intel/bin/ifort linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
configure: finding other utilities
checking for a BSD-compatible install... /usr/bin/install -c
configure: trying to set fortran flags for this platform
configure: trying to set flags for this platform
checking if _HPUX_SOURCE should be set... no
checking if Solaris -Xa option is needed... CFLAGS=-g -O2
configure: trying to set fortran 90 flags for this platform
checking if we need to add to FFLAGS for ifort compiler... FFLAGS=-g
checking if we need to set _LARGE_FILES despite results of previous tests... _LARGE_FILES=
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
configure: displaying some results
checking CPPFLAGS... 
checking CC CFLAGS... cc -g -O2
checking type cc... cc is /usr/bin/cc
checking CXX... c++
checking CXXFLAGS... -g -O2
checking type c++... c++ is /usr/bin/c++
checking FC... /home/patti/intel/bin/ifort
checking FFLAGS... -g
checking type /home/patti/intel/bin/ifort... /home/patti/intel/bin/ifort is /home/patti/intel/bin/ifort
checking F90... /home/patti/intel/bin/ifort
checking F90FLAGS... 
checking type /home/patti/intel/bin/ifort... /home/patti/intel/bin/ifort is /home/patti/intel/bin/ifort
checking AR... ar
checking AR_FLAGS... cru
checking type ar... ar is /usr/bin/ar
checking NM... /usr/bin/nm -B
checking NMFLAGS... 
checking for /usr/bin/nm... /usr/bin/nm -B
checking nm flags... 
checking for C-equivalent to Fortran routine "SUB"... sub_
checking for Fortran "byte"... yes
checking for Fortran "integer*2"... yes
checking if Fortran "byte" is C "signed char"... yes
checking if Fortran "byte" is C "short"... no
checking if Fortran "byte" is C "int"... no
checking if Fortran "byte" is C "long"... no
checking if Fortran "integer*2" is C "short"... yes
checking if Fortran "integer*2" is C "int"... no
checking if Fortran "integer*2" is C "long"... no
checking if Fortran "integer" is C "int"... yes
checking if Fortran "real" is C "float"... yes
checking if Fortran "doubleprecision" is C "double"... yes
checking for Fortran-equivalent to netCDF "byte"... byte
checking for Fortran-equivalent to netCDF "short"... integer*2
checking if Fortran 90 compiler capitalizes .mod filenames... no
configure: checking types, headers, and functions
checking for stdlib.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for strlcat... no
checking for strerror... yes
checking for working alloca.h... yes
checking for alloca... yes
checking whether isnan is declared... yes
checking whether isinf is declared... yes
checking whether isfinite is declared... yes
checking whether signbit is declared... yes
checking for struct stat.st_blksize... yes
checking for IEEE floating point format... yes
checking for size_t... yes
checking for off_t... yes
checking for ssize_t... yes
checking for ptrdiff_t... yes
checking for uchar... no
checking whether char is unsigned... no
checking whether byte ordering is bigendian... no
checking size of short... 2
checking size of int... 4
checking size of long... 8
checking size of float... 4
checking size of double... 8
checking size of off_t... 8
checking size of size_t... 8
checking for manual-page index command... 
checking what to call the output of the ftpbin target... binary-netcdf-3.6.3_nc3_/home/patti/intel/bin/ifort_/home/patti/intel/bin/ifort_c++.tar /home/patti/intel/bin/ifort c++
checking binary distribution directory... /home/ftp/pub/binary/dummy_system
checking for gawk... (cached) gawk
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
configure: generating header files and makefiles
configure: creating ./config.status
config.status: creating Makefile
config.status: creating man/Makefile
config.status: creating man4/Makefile
config.status: creating fortran/Makefile
config.status: creating libsrc/Makefile
config.status: creating libsrc4/Makefile
config.status: creating nctest/Makefile
config.status: creating nc_test4/Makefile
config.status: creating nc_test/Makefile
config.status: creating ncdump/Makefile
config.status: creating ncgen/Makefile
config.status: creating nf_test/Makefile
config.status: creating cxx/Makefile
config.status: creating cxx4/Makefile
config.status: creating f90/Makefile
config.status: creating examples/Makefile
config.status: creating examples/C/Makefile
config.status: creating examples/CDL/Makefile
config.status: creating examples/CXX/Makefile
config.status: creating examples/CXX4/Makefile
config.status: creating examples/F90/Makefile
config.status: creating examples/F77/Makefile
config.status: creating win32/Makefile
config.status: creating win32/NET/Makefile
config.status: creating win32/NET/libsrc/Makefile
config.status: creating win32/NET/ncdump/Makefile
config.status: creating win32/NET/ncgen/Makefile
config.status: creating win32/NET/examples/Makefile
config.status: creating win32/NET/nctest/Makefile
config.status: creating win32/NET/nc_test/Makefile
config.status: creating config.h
config.status: creating fortran/nfconfig1.inc
config.status: executing depfiles commands
config.status: executing libtool commands

linux-68t00:/usr/local/netcdf-3.6.3 # make

make  all-recursive
make[1]: Entering directory '/usr/local/netcdf-3.6.3'
Making all in f90
make[2]: Entering directory '/usr/local/netcdf-3.6.3/f90'
/bin/sh ../libtool   --mode=compile /home/patti/intel/bin/ifort -I../libsrc -I.  -g -c -o typeSizes.lo typeSizes.f90
libtool: compile:  /home/patti/intel/bin/ifort -I../libsrc -I. -g -c typeSizes.f90 -o typeSizes.o
/bin/sh ../libtool   --mode=compile /home/patti/intel/bin/ifort -I../libsrc -I.  -g -c -o netcdf.lo netcdf.f90
libtool: compile:  /home/patti/intel/bin/ifort -I../libsrc -I. -g -c netcdf.f90 -o netcdf.o
/bin/sh ../libtool   --mode=link /home/patti/intel/bin/ifort -I../libsrc -I.  -g   -o libnetcdff90.la  typeSizes.lo  netcdf.lo  
libtool: link: ar cru .libs/libnetcdff90.a  typeSizes.o netcdf.o
libtool: link: ranlib .libs/libnetcdff90.a
libtool: link: ( cd ".libs"&& rm -f "libnetcdff90.la"&& ln -s "../libnetcdff90.la""libnetcdff90.la" )
make[2]: Leaving directory '/usr/local/netcdf-3.6.3/f90'
Making all in fortran
make[2]: Entering directory '/usr/local/netcdf-3.6.3/fortran'
echo '!     NetCDF-3.'> netcdf.inc
cat ../fortran/netcdf3.inc >> netcdf.inc
echo >> netcdf.inc
echo '!     NetCDF-2.'>> netcdf.inc
cat ../fortran/netcdf2.inc >> netcdf.inc
make  all-am
make[3]: Entering directory '/usr/local/netcdf-3.6.3/fortran'
depbase=`echo fort-attio.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../libtool --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I. -I..     -I../libsrc    -g -O2 -MT fort-attio.lo -MD -MP -MF $depbase.Tpo -c -o fort-attio.lo fort-attio.c &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I../libsrc -g -O2 -MT fort-attio.lo -MD -MP -MF .deps/fort-attio.Tpo -c fort-attio.c -o fort-attio.o
In file included from ncfortran.h:12:0,
                 from fort-attio.c:7:
cfortran.h:138:3: error: #error "cfortran.h:  Can't find your environment among:    - MIPS cc and f77 2.0. (e.g. Silicon Graphics, DECstations, ...)         - IBM AIX XL C and FORTRAN Compiler/6000 Version 01.01.0000.0000         - VAX   VMS CC 3.1 and FORTRAN 5.4.                                      - Alpha VMS DEC C 1.3 and DEC FORTRAN 6.0.                               - Alpha OSF DEC C and DEC Fortran for OSF/1 AXP Version 1.2              - Apollo DomainOS 10.2 (sys5.3) with f77 10.7 and cc 6.7.                - CRAY                                                                   - NEC SX-4 SUPER-UX                                                      - CONVEX                                                                 - Sun                                                                    - PowerStation Fortran with Visual C++                                   - HP9000s300/s700/s800 Latest test with: HP-UX A.08.07 A 9000/730        - LynxOS: cc or gcc with f2c.                                            - VAXUltrix: vcc,cc or gcc with f2c. gcc or cc with f77.                 -            f77 with vcc works; but missing link magic for f77 I/O.     -            NO fort. None of gcc, cc or vcc generate required names.    - f2c    : Use #define    f2cFortran, or cc -Df2cFortran                 - NAG f90: Use #define NAGf90Fortran, or cc -DNAGf90Fortran              - Absoft UNIX F77: Use #define AbsoftUNIXFortran or cc -DAbsoftUNIXFortran     - Absoft Pro Fortran: Use #define AbsoftProFortran     - Portland Group Fortran: Use #define pgiFortran     - PathScale Fortran: Use #define PATHSCALE_COMPILER"
  #error "cfortran.h:  Can't find your environment among:\
   ^~~~~
make[3]: *** [Makefile:426: fort-attio.lo] Error 1
make[3]: Leaving directory '/usr/local/netcdf-3.6.3/fortran'
make[2]: *** [Makefile:298: all] Error 2
make[2]: Leaving directory '/usr/local/netcdf-3.6.3/fortran'
make[1]: *** [Makefile:362: all-recursive] Error 1
make[1]: Leaving directory '/usr/local/netcdf-3.6.3'
make: *** [Makefile:292: all] Error 2

Hi all,

this is a question and a feature request just in case someone at Intel is interested.

The source below compiles without warnings, and fails at run-time. In my understanding, the code violates language rules (please correct me here, if I am wrong). It would therefore be neat if the compiler would issue a compile-time warning in situations like that; it took me quite some time to identify a similar issue.

Description:

The code contains an extended derived type (Child) which overwrites a type-bound procedure binding. However, the overwritten binding's (Child_sub) dummy argument (class(X)) characteristics differ from the overwritten binding (type(X)). The corresponding source lines are marked by an asterisk (*).

Terminal output:

ifort test.f90 -g -trace
./a.out
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
a.out              0000000000403AF3  Unknown               Unknown  Unknown
libpthread-2.27.s  00007F2987317890  Unknown               Unknown  Unknown
a.out              0000000000402ADF  m_mp_child_sub_            25  test7.f90
a.out              0000000000402C71  MAIN__                     37  test7.f90
a.out              0000000000402A82  Unknown               Unknown  Unknown
libc-2.27.so       00007F2986D31B97  __libc_start_main     Unknown  Unknown
a.out              000000000040296A  Unknown               Unknown  Unknown

Modification:

Swap type and class attributes in lines marked by (*).

Modification terminal output:

ifort test.f90
./a.out 
     7046112

Source "test.f90":

module m
    type :: X
        integer :: i = 1
    end type

    ! Parent and Child
    type :: Parent
    contains
        procedure, nopass :: sub => Parent_sub
    end type
    type, extends(Parent) :: Child
    contains
        procedure, nopass :: sub => Child_sub
    end type

contains 
    ! Parent subroutine
    subroutine Parent_sub(a)
        class(X) :: a        ! (*)
    end subroutine

    ! Child subroutine
    subroutine Child_sub(a)
        type(X) :: a        ! (*)
        print *, a%i
    end subroutine
end module

program test
    use m
    implicit none

    type(X) :: a
    class(Parent), allocatable :: myChild
    allocate(Child::myChild)

    call myChild%sub(a)
end program

Details:

• Product Version: Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.3.199 Build 20190206
• Host OS and Version: Ubuntu 18.04.2 LTS Release: 18.04 Codename: bionic

Kind regards
Ferdinand

If you have a type bound procedure and within the same module I do:
 

!$omp simd

do i =1,N

(...)

  call this%  AN_ELEMENTAL_INLINE_ROUTINE

(..)

enddo

My optimisation report says that it was unable to inline indirect call list.

1 ) I would understand this complain if my type bound procedure could be overridden, however, i tried to explicitly set a `non_overridable` it did not help either.

2) If I got a procedure which is deferred /overridden, I obviously would not be able to ask the compiler to inline it. However, does anybody in here know whether or not such loops can still benefit from vectorisation. I initially thought to put the "!$OMP DECLARE SIMD(ROUTINE_NAME)" on every potential routine that would overwrite the type bound procedure .

e.g.

type  test

contains

procedure  :: init => init_1

end type

type extend(test) :: test_2

contains

procedure init=> init_2

end type

!$omp declare simd(init_2)

subroutine init_2(....)

end subroutine

!$omp declare simd(init_1)

subroutine init_1(....)

end subroutine

now im using windows 10 with visual studio 2019. im thinking to migrate to linux to have more stability and better performance for my calculations(some of then take more than 2 weeks). but i dont know whichdistro i choose. i need just few things: a good ide and paraview. someone could help me?
thank you

I have found a bug in the intel ifort compiler 2019.3.199. I try to read real data into a complex variable using the following code: read(2) CFL%re

read(2) W%re

When doing so I get the following error: "Constants and expressions are invalid in read-only" Given that ifort claims it is fortran 2008 compliant, and that this capability is part of the 2008 standard, I believe I have found a bug.

Dear all,

I am posting two situations that rise internal compiler errors in the hope that it helps others to avoid lengthy and annoining searches for the cause of the compiler crash, and in case Intel engineers are interested.
Both errors are triggered by invalid uses of type-bound procedures, such as forgetting the parentheses in a function call.

source A:

module m
    ! derived type ----------
    type :: X
        integer :: x_comp
    contains 
        procedure, nopass :: x_bind
    end type
contains
    subroutine x_bind()
    end subroutine

    ! trigger crash ---------
    subroutine CRASH()
        type(X) :: myX

        ! use binding name as keyword
        myX = X(x_bind=1.0d0)
    end subroutine
end module

! compiler output -----------
! test9.f90: 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.
! compilation aborted for test9.f90 (code 1)

Source B:

module m
    ! derived type ----------
    type :: X
    contains 
        procedure, nopass :: x_bind
    end type
contains
    subroutine x_bind
    end subroutine

    ! trigger crash ---------
    subroutine crash()
        type(X) :: myX
        logical :: expr

        ! apply any logical operator to non-existing
        ! component that corresponds to a binding name
        expr = .not. myX%x_bind
    end subroutine
end module

! compiler output -----------
! test10.f90(18): catastrophic error: **Internal compiler error: internal abort** 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.
! compilation aborted for test10.f90 (code 1)

System Info:

• Product Version: Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.3.199 Build 20190206
• Host OS and Version: Ubuntu Description: Ubuntu 18.04.2 LTS Release: 18.04 Codename: bionic

Kind regards
Ferdinand

I'm trying to implement code that takes two different paths, depending on whether a compile-time macro is set.  My source file (shortened for clarity):

    SUBROUTINE FFTCT(Z, N)

#ifdef WITH_MKL
    USE MKL_DFTI
#endif

    IMPLICIT NONE
    INCLUDE 'CMKL.TEXT'

    COMPLEX*8   Z(N)
    INTEGER*4    N
{...}

#ifdef WITH_MKL
    {MKL-specific section}
    RETURN
#endif

{non-MKL section}
    END

And CMKL.TEXT:

    LOGICAL*1  USE_MKL

#ifdef WITH_MKL
    type(DFTI_DESCRIPTOR), POINTER :: FFT_HANDLE
    type(DFTI_DESCRIPTOR), POINTER :: IFFT_HANDLE
#endif

    COMMON/FFT_CFG/ USE_MKL

#ifdef USE_MKL
  &  , FFT_HANDLE,
  &    IFFT_HANDLE
#endif

When I try to compile a module for this routine with "ifort -module ./mods/ -warn noalignments -DWITH_MKL -extend-source 132 -assume nounderscore -gen-interfaces nosource -syntax-only fftct.fpp", everything goes fine.  However, if you remove the WITH_MKL definition from the command line, you receive errors about the DFTI_DESCRIPTOR type not being declared.  If I instead don't put those variables in the INCLUDE file, and instead place them directly in the compilation unit, the module file is generated without issue in both cases.  So it appears as though the preprocessor directives are not being carried into included files, and are only being applied at the top-level file.  Is this expected behavior?

Using ifort 18.0.5.