Attempting to compile a file that requires preprocessing, the output of the preprocessor is saved in the current working folder, irrespective of the -[no-]save-temps and -[no]keep flags.  If you compile a file that has a .fpp extension (using the "-c" flag, for example on "test.fpp"), you only receive the output file as test.o in the working folder.  However, if you run the same compiler switches but replace the "-c" with "-syntax-only", the compiler leaves the "temp.i" file in the current folder.

Using ifort 18.0.5

This note applies to the Intel^® Compilers for macOS* only.  

There are known issues with the Intel Compilers running under macOS* 10.15 Catalina and Xcode* 11 which are currently, as of 29 August 2019, still in beta.  We are advising macOS* customers to delay upgrading to macOS 10.15 Catalina until we are able to add support and validate our software against the "Gold" release of Catalina.   We intend to support macOS* 10.15 Catalina and Xcode* 11 in a future compiler update release.  Please wait or delay your macOS* and Xcode* upgrade until we deliver a future compiler release where we explicitly state support for macOS* 10.15 Catalina and Xcode* 11.  Visit the Release Notes for the list of officially supported OS and Xcode* combinations. 

DETAILS

Apple has implemented a new and addition process for developers intending to support the forthcoming macOS Catalina.  In the past, application developers such as Intel had to digitally sign (get a certificate for ) our installer applications with Apple to insure that the installer is from a known and trusted application developer.  The Intel Compilers and tools installers have included this digital signature for many years.  However, with Catalina application developers have a new step - developers must submit their apps to Apple's notarizing security process, allow Apple to scan the application for known security issues, and obtain from Apple a new  "Application Signature" or Notarization along with the existing digital certificate and include the certificate and notarization along with the applications. Without this new and additional notarization they will not run on Catalina.  Gatekeeper on Catalina will not allow current Intel installers ( all Intel^® Parallel Studio XE Composer Edition for macOS* versions 2019 Update 4 and older) to run.  Thus, once you upgrade to Catalina you will no longer be able to run current ( 2019 Update 4 and older ) installers.  Intel will only begin suppling installers with this new notarization in a future release.  Existing releases do not have this notarization and we will not repackage and re-release existing packages to add this support.  We will add Catalina support with this new notarization in a future release.

If you do upgrade to Catalina at some point, keep in mind that you will be unable to install and hence run previous versions of the Intel Compilers for macOS* under Catalina.  

IF you have already installed Intel Compilers on your macOS* `10.14 or older and then upgrade to Catalina we believe the compilers will continue to run from the command line interface.  However, we have not officially validated our compilers and libraries and tools against Catalina.  There may be incompatibilities of older tools with Catalina.  Visit the Release Notes for the list of officially supported OS and Xcode* combinations. 

Xcode*:  Existing Xcode 10.x integrations will remain.  If you upgrade to Xcode* 11 you will lose Xcode integrations AND you will NOT be able to install the Xcode* 11 integrations since the current 2019 Update 4 and older installers will not run on Catalina. We have not validated our compiler integrations with Xcode* 11 Gold either.  Official support for Xcode* 11 is coming in a future release.
 

Hello,

I'm using ifort to compile a scientific code with openmp parallelization, the relevant code's section is :

!$omp parallel do schedule(static,1)

  do j = 2,n-1

    do i = 2, m - 1

     w(i,j) = 0.25 * (u(i-1,j)+u(i+1,j)+u(i,j-1)+u(i,j+1)  )
     
    end do
  end do

!$omp end parallel do

where n and m are very big.

I compile with : ifort -o stencil  -qopenmp -Ofast -fno-alias -qopt-report  stencil.f90

The interesting part of report is this :

stencil.f90(#linewithstencil,23):remark #34055: adjacent dense (unit-strided stencil) loads are not optimized. Details: stride { 4 }, step { 8 }, types { F32-V128, F32-V128 }, number of elements { 4 }, select mask { 0x000000003 }.
stencil.f90(#linewithstencil,23):remark #34055: adjacent dense (unit-strided stencil) loads are not optimized. Details: stride { 4 }, step { 8 }, types { F32-V128, F32-V128 }, number of elements { 4 }, select mask { 0x000000003 }.
stencil.f90(#linewithstencil,23):remark #34055: adjacent dense (unit-strided stencil) loads are not optimized. Details: stride { 4 }, step { 8 }, types { F32-V128, F32-V128 }, number of elements { 4 }, select mask { 0x000000003 }.
stencil.f90#linewithstencil,23):remark #34055: adjacent dense (unit-strided stencil) loads are not optimized. Details: stride { 4 }, step { 8 }, types { F32-V128, F32-V128 }, number of elements { 4 }, select mask { 0x000000003 }.

Is compiler suggesting some improvement for perfomance ? I must say speedup is pretty bad, at least on my laptop. Thank you
 

Hello:

I am using ifort (IFORT) 17.0.4 20170411

I am trying to paralelize a DO loop using OpenMP. I compile using -qopenmp.
The code is large and I suspect that I can easily overlook importatn parts if I try to write a minimal example.

When I use the !$OMP PARALLELDO PRIVATE (...) ... !$OMP END PARALLELDO, only one thread is created and it makes the whole loop.

When I use !$OMP PARALLEL ... !$OMP END PARALLEL, and inside of it I use !$OMP DO ... !$OMP END DO, all the 20 threads are created, and all of them are working, but each thred is running the whole loop, id est, the variable that serves as the counter of the do loop, takes, for each thread, all its values, so that the complete loop is being run 20 times, one per thread.

It seems that the !$OMP PARALLEL is being completely ignored, but there are no warnings from the compiler.

I use alloatable arrays that are allocated before the pallalelized loop, and are declared as private in the PRIVATE clause. Could this perhaps have something to do?.

Here, some output for the last case:

Number of requested cores: 20
Thread_000 Problem_day_0000001
Thread_001 Problem_day_0000001
Thread_003 Problem_day_0000001

The loop counter is "Problem_day"

When I omit the $OMP DO ... !$OMP END DO and make the partition of the loop by myself, the job is ditributed among the threads and it seems not to be any problem.

I am dealing with millions of sequential repetitions of the removal of the N-th element from 1D dynamic array that has been allocated size M(>=N) before the removal of the element (the integers N and M change before each repetition of the array element removal). The syntax I use is:

 A=[A(:N-1),A(N+1:)]

This removes the Nth element and changes the size of the real*8 array A from M to M-1. This step is revisited again and again millions of times as it is part of a DO loop with other operations taking place before and after this step (which may also change M).

I also tried another syntax:

A(N)=999.
A=PACK(A,A.ne.999.)

(the elements of my array are all different from 999. to start with so the PACK with the MASK removes the modified N-th element and shrinks the size of the array by 1).

Both methods are simply too slow when you have to repeat the step sequentially millions of times. My array size M is typically between 100000 and 1000000.

Can anybody suggest an alternative method that is faster? I compile using -O3 optimisation although it makes no real difference. Is there anything in the MKL library that could be of use?

I'm looking to get a hold of the Fortran runtime libraries.

I have access to the gfortran compiler, but the libraries are not necessarily available.  Are the runtime libraries available on their own?  Or are they apart of some larger software package?

I tried to call to get this information, but was direct to post here so I hope I'm in the right place.

Thank you!

I have Intel fortran running on a linux machine. I also have Visual Studio running on  a mac. Is it possible to use the mac to remotely edit, debug, compile and run Fortran applications on a Linux machine? 

According to Intel documentation, v19 of the Intel Linux compiler is compatible with gcc 4.4 to gcc 7. Unfortunately, a customer of mine is using gcc 8, requires interoperability with c, and is having problems with Intel Fortran v19 .so builds because they have been built with the gcc 7 libraries. I am using Ubuntu 18.04 LTS, and the Ubuntu repository offers gcc v8.

Has anyone reading this forum successfully used the Intel compiler with gcc 8 for c interoperability? What can go wrong and are there any work-arounds? Thanks for any insight.

Suppose I have an array

real, pointer :: foo(:)

which gets allocated as

allocate(foo(nfoo))

and then passed into a subroutine:

subroutine bar(...,nfoo,...,foo,...)
integer, intent(in) :: nfoo
real, intent(in) :: foo(nfoo) ! OPTION A
! OR
real, dimension(nfoo), intent(in) :: foo ! OPTION B
! OR
real, dimension(:), intent(in) :: foo ! OPTION C

What happens if nfoo == 0 ?

I know that zero-sized arrays are allowed in Fortran and that option A works, according to this conversation: https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux... 

What about option B and C? I am getting different results when compiling the code with optimization turned on (-O2, AVX2) with option C.

Thanks,

Dom

I read about this topic on the Windows forum (see topic DLL can't see main program's shared variables) and also got it working  on Windows mainly based on the example in post #5 from IanH (Blackbelt) Wed, 12/13/2017 - 00:54  there.

My question is now how to properly do exactly the same in Linux.

I got it some how working by adding the "-Wl,--export-dynamic" when compiling the main executable, but this for sure then now exports all symbols of that (which I don't want).
So I assume there should be some equivalent of the "!DEC$ ATTRIBUTES DLLEXPORT :: var" to mark only a distinct variable or function for export also under Linux.

Additionally I like the fact of the export library being created when compiling the main executable which then is used when linking the DLL to resolve the symbols. - With this then one can also successfully check that all symbols are actually resolved already at link-time.
For Linux, I did not succeed in checking this at link time... - I get a lot of unresolved warnings when using the ld flag to output them and I do not see how to tell ld to check them where against... (i.e. would be the main executable).

Thanks,
Frank

Hello,

I am trying to look for a method where I can apply a certain procedure consistently to all components of a derived type.  It can be anything where I need apply the same operations to all components of a derived type. Now, when I later on add an extra component to the derived type, I need likewise to adopt the procedures to incorporate that change.

Imagine this very simple scenario where I need to initialize all my components to a certain value.

subroutine reset(this,val) 
type(t_mod) :: this 
real :: val


do i = this% size_ 
   this% a(i) = val
   this% b(i) = val 
   this% c(i) = val 

enddo 

end subroutine

Another example is the routine which allocates all components. That likewise requires a similar approach as above.

If I later add a component "d" to my "t_mod" declared type I need manually to go to the reset subroutine and introduce the

"this% d(i) = val" ..

How can I abstract this so my procedure "reset" is executed consistently to all components of the derived type.

 In my code I have many of such subroutines which requires operations on all components. At this time I am getting frustrated that whenever I add an extra component to my t_mod", I need to go through all these routine to add that extra component.

Is it possible to find an abstraction to this in Fortran or mixing with c/c++

Thanks

Following program: 

      program bsccbroken                                                                                                                                                         

      write(*,*) '\"ABCDEF\"'
      write(*,*) '\"ABCDEF\"\0'
      write(*,*) '\"#\"'
      write(*,*) '\"#\"\0'

      end program bsccbroken

When compiled with ifort version 15.0.2:

ifort -assume bscc -warn all -g -o bscc bscc.f

Produces following output:

[bma@localhost f]$ ./bscc
 "ABCDEF"
 "ABCDEF
 "#"
 "#
 

Please notice that closing quote is not included when \0 is appended to the end of the string. I work with large legacy code base where those closing zero bytes (\0) are very often included to ensure interoperability with C APIs.

While using IBM fortran xlf90 produces expected result:

$ xlf90 -o bscc bscc.f
** bsccbroken   === End of Compilation 1 ===
1501-510  Compilation successful for file bscc.f.
$ ./bscc
 "ABCDEF"
 "ABCDEF"
 "#"
 "#"
 

Is it well known problem with -assume bscc option? Is there a patch for this? Is this behavior different in newer versions of Composer Studio?

Thanks in advance for any information.

Hi, I'm trying to use JAVA call Fortran *.so file. The *.so file is just a "Print Hello" test. I first tried Fortran call Fortran, it worked just fine. But in my JAVA System.load("*.so") code, I got an error that that : libifcoremt.so.5: undefined symbol: tbk_string_stack_signal_impl

So I tried ldd -r *.so，and it showed the same error, and I tried ldd -r libifcoremt.so.5，it showed that there're several undefined symbols,

undefined symbol: pthread_key_create (./libifcoremt.so.5)
undefined symbol: dlsym (./libifcoremt.so.5)
undefined symbol: pthread_getspecific (./libifcoremt.so.5)
undefined symbol: pthread_setspecific (./libifcoremt.so.5)
undefined symbol: tck_string_stack_signal_impl (./libifcoremt.so.5)

And I tried c++filt tbk_string_stack_signal_impl

But the result is just

tbk_string_stack_signal_impl

So I don't know where the problem is.

Can you help me please. Thx so much.

i have a student license for windows and i want to migrate for linux but i cant retrieve a student license for linux, what i do?

Hello,

the code below causes the compiler to crash badly, while it presumably is legal Fortran.
I post this in case someone is interested or even wants to report this to Intel.

Description:

Type(X) recursively contains an allocatable type(X) component.
Using type(X) in a subprogram as intent(out) dummy argument, or as a function result (see example) causes a compiler crash.

Code:

module m
    implicit none
    type :: X
        type(X), allocatable :: a
    end type
contains
    type(X) function f
    end function
end module

Output:

$ ifort test.f90 -c
ifort: error #10105: /opt/intel/compilers_and_libraries_2019.3.199/linux/bin/intel64/fortcom: core dumped
ifort: warning #10102: unknown signal(-1269299024)
ifort: error #10106: Fatal error in /opt/intel/compilers_and_libraries_2019.3.199/linux/bin/intel64/fortcom, terminated by unknown
compilation aborted for test.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

"[root@localhost parallel_studio_xe_2019.5.075]# source psxevars.sh
Intel(R) Parallel Studio XE 2019 Update 4 for Linux*
Copyright (C) 2009-2019 Intel Corporation. All rights reserved.
[root@localhost parallel_studio_xe_2019.5.075]# ifort -fast /opt/intel/parallel_studio_xe_2019.5.075/hgropelli260820191035_beta01.f90
/opt/intel/parallel_studio_xe_2019.5.075/hgropelli260820191035_beta01.f90(4529): warning #5462: Global name too long, shortened from: granular_sphere_in_given_fluid_flow_classcompute_granular_sphere_igff_environment_forces_mp_COMPUTE_LOCAL_FLUID_VELOCITY to: d_flow_classcompute_granular_sphere_igff_environment_forces_mp_COMPUTE_LOCAL_FLUID_VELOCITY
  SUBROUTINE compute_local_fluid_velocity
-------------^
ld: cannot find -lm
ld: cannot find -lc
ld: cannot find -ldl
ld: cannot find -lc"

i dont have ideia what is happenning, im running on centos7.

I am trying to track down run-time libraries (specifically libm*.a/.so) released in Composer 2013 SP1 R3 for Linux.

We use Fortran 2013 SP1 R3 on Windows and recently ported some code to Linux gfortran.  However, we have observed small numerical differences in results originating in run-time math routines (exp and trigonometric functions), leading to the least significant bit being off by one in cross-platform comparisons.

In an attempt to eliminate these differences have integrated libmmd.dll on Windows and am looking for the Linux equivalent.

Can anyone point me in the direction of these libraries for Linux? 

Thank you.

Hi

After I update my mac os from 10.10 to 10.11 xcode does not recognize intel fortran compiler . I did some modification which was changing the address of compiler manually to intel fortran compiler installed directory in ifort plugins file which was in :

/Library/Application Support/Developer/6.4/Xcode/Plug-ins/IFORT 15.0 Compiler.xcplugin

my xcode version was 6.4 and intel compiler was 2015 update 2 . everything was fine (except debugger when using module or allocatable variable ) . again I updated my mac to Sierra in last week and Xcode 6.4 was not compatible with this version of mac so I updated my xcode to 8.0 . again xcode did not recognized my intel fortran compiler . after some searching web I find out I have to create a Shared folder and put the plugin inside it like :

/Library/Application Support/Developer/Shared/Xcode/Plug-ins/IFORT 15.0 Compiler.xcplugin

Now xcode recognize my intel fortran compiler but when i use build ther is a error ( intel fortran works in terminal and I can compile my fortran file inside terminal using ifort myfile)

ipo: warning #11016: Warning unknown option -no_deduplicate

ld: file not found: /Users/Alfred/Library/Developer/Xcode/DerivedData/main-cmdzktxskmwirzcgutlzgyrrqxgd/Build/Intermediates/main.build/Debug/main.build/Objects-normal/x86_64/main_lto.o

Command /opt/intel/composer_xe_2015.2.132/bin/intel64/ifort failed with exit code 1

I Updated the DVTPlugInCompatibilityUUID in info.plist with xcode 8 UUID but still get this error . 

Hi all, i'm trying to build netcdf-4.4.1. with intel parallel studio xe 2016 update 3 in Red Hat Enterprise Linux Server 7.2, following this url:

https://software.intel.com/en-us/articles/performance-tools-for-software-developers-building-netcdf-with-the-intel-compilers

It presentsthe following error whenrunning make:

libtool: compile:  icc -DHAVE_CONFIG_H -I. -I.. -I../include -I/opt/hdf5/include -I/opt/curl/include -O3 -xHost -ip -no-prec-div -static-intel -MT libnetcdf4_la-nc4file.lo -MD -MP -MF .deps/libnetcdf4_la-nc4file.Tpo -c nc4file.c  -fPIC -DPIC -o .libs/libnetcdf4_la-nc4file.o
nc4file.c(2322): error: identifier "H5LT_FILE_IMAGE_DONT_COPY" is undefined
                        H5LT_FILE_IMAGE_DONT_COPY|H5LT_FILE_IMAGE_DONT_RELEASE
                        ^

nc4file.c(2322): error: identifier "H5LT_FILE_IMAGE_DONT_RELEASE" is undefined
                        H5LT_FILE_IMAGE_DONT_COPY|H5LT_FILE_IMAGE_DONT_RELEASE
                                                  ^

compilation aborted for nc4file.c (code 2)
make[2]: *** [libnetcdf4_la-nc4file.lo] Error 1
make[2]: Leaving directory `/root/libs/netcdf-4.4.1/libsrc4'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/libs/netcdf-4.4.1'
make: *** [all] Error 2
^C[1]+  Exit 2                  make &>make.log

Any ideas to fix this?

Thanks in advance

I am running into an issue with compiling code with ifort 16 which worked with previous versions of ifort and works with e.g. gfortran. The code in question is here:

https://gist.github.com/astrofrog/47ee268a8e71dc6760ec3e0e1b4beca7

and I have put a tar file for convenience here:

https://dl.dropboxusercontent.com/u/3770121/ifort_issue.tgz

I have tried to boil it down to as simple a code as possible. When compiling using make.sh, I get the following error:

grid_geometry_cartesian_3d.f90(11): error #6457: This derived type name has not been declared.   [GRID_CELL]

  type(grid_cell) :: cell

-------^

compilation aborted for grid_geometry_cartesian_3d.f90 (code 1)