Reference Number : DPD200139304


Version : 11.1


Operating System : All


Problem Description : The compiler will incorrectly issue diagnostic 6405: The same named entity from different modules and/or program units cannot be referenced, in the following situation:

1. A procedure (subroutine or function) is declared with an implicit interface (just a type and/or EXTERNAL) in a module.
2. A program unit USEs the module and calls the procedure twice or more.
3. The application is compiled with the generated interface checking feature enabled. (From the command line, the option /warn:interface (Windows) or -warn interface (Linux and Mac OS X); in the Visual Studio development environment, property Fortran > Diagnostics > Check Routine Interfaces is set to Yes.)

Example:

module MYMOD
logical, external :: func
end module MYMOD

program MAIN
use MYMOD
print *, FUNC(0)
print *, FUNC(1)
end program MAIN

Resolution Status : This error will be corrected in a future product version. The simplest workaround is to recode the declaration in the module as an INTERFACE block.  For example:

module MYMOD
interface
logical function FUNC (ARG)
integer, intent(IN) :: ARG
end function FUNC
end interface
end module MYMOD

If the procedure is written in Fortran, a preferable alternative is to place it in the module as a module procedure. This avoids the need to write a separate declaration of the procedure, but does require that any caller USE the module.

For information on other causes of this error, see Diagnostic 6405: The same named entity from different modules and/or program units cannot be referenced.



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200138822


Version : 10.1, 11.0, 11.1


Operating System : Linux*, Mac OS X* / IA-32, Intel® 64, IA-64


Problem Description : 

Both the Intel Fortran and C++ compilers for Mac OS and Linux quietly ignore the invalid option -i and pass it to the linker.

The effect is harmless on Mac OS because the linker (ld) does not support the -i option.

For example:

$ ifort -V -i sample.f90
Intel(R) Fortran Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090511 Package ID: m_cprof_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
ld: unknown option: -i

The effect is not harmless on Linux where both compiler driver's (icc, ifort) quietly passing the option to the linker (ld) turns on incremental linking. Incremental linking produces a non-executable LSB relocatable file and not a LSB executable file.

Because the incremental linking is done quietly it leads to user confusion when trying to execute the non-executable LSB relocatable file. The attempt to execute the resulting file results in a "Permission denied" error.

The demonstration below shows how the invalid -i option leads to this confusing situation and error.

$ ifort sample.f90 -o sample

$ file sample
sample: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ ifort -i sample.f90 -o sample

$ file sample
sample: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped

$ ./sample
-bash: ./sample: Permission denied


$ icc sample.c -o sample

$ file sample
sample: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ icc -i sample.c -o sample

$ file sample
sample: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped

$ ./sample
-bash: ./sample: Permission denied

Resolution Status : This is a known issue that will be fixed in a future release. Since -i is not a valid Intel compiler option, correcting or removing the option will resolve the issue.



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200138566


Version : 11.0, 11.1


Operating System : Linux*, Mac OS X* / IA-32, Intel® 64, IA-64


Problem Description : 

Beginning with the 11.x release, the Intel Fortran compiler does not correctly ignore the -extend-source (and other variants) for free-form source files named with the .F90 extension. The option is correctly ignored for source files named with the lower-case .f90 extension.

The mishandling of the option will cause erroneous syntax errors for any Fortran source statement that extends beyond the designated statement field length specified with the -extend-source option.

The example below demonstrates the extraneous errors issued when using -extend-source 132 with the sample program containing an OPEN statement extending beyond 132 characters.

Given the following sample.F90 source:

program sample

open(unit=10,file='/hardware/temporary/model/simulation/version/9.999/xray/store/detection/reflection/fulltrace/resolution/images7654.txt',status='replace',iostat=ios_100)

if(ios_100/=0) then
   print *,"File open failed"
endif

end

$ ifort -V -c -extend-source 132 sample.F90
Intel(R) Fortran Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cprof_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

Intel(R) Fortran 11.1-2536
sample.F90(3): error #5120: Unterminated character constant
open(unit=10,file='/hardware/temporary/model/simulation/version/9.999/xray/store/detection/reflection/fulltrace/resolution/images76&
------------------^
sample.F90(4): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: ) ,
&5
--^
compilation aborted for sample.F90 (code 1)

Resolution Status : This is a known issue that will be fixed in a future release. Since -extend-source is not intended to apply to free-form source files, to work around this current defect simply avoid usage with any .F90 source files.


[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Problem : 

During installation, an error message of "Error while copying license file. Please make sure you have write permission to the license folder" will result if the user does not have write permission to the directory /Users/Shared/Library/Application\ Support/Intel/Licenses.

Environment : 

Mac OS X, Intel Compiler 11.1

A related article pertaining to Mac OS X, Intel Compiler 9.1, 10.1, 11.0 can be found here.


Root Cause : 

The error "Error while copying license file. Please make sure you have write permissions to the license folder." will appear if the user does not have write permission to the directory /Users/Shared/Library/Application\ Support/Intel/Licenses.

This directory by default has write permission enabled, however, installation of other third party products such as Adobe products might change the permission for this directory. This change in permission will result in an error during installation of Intel(R) Compiler Products because the installer can not create a license file in this directory.

Even if the user provide their own license file instead of a serial number, the error will still occur if the installer can not copy the license to the directory /Users/Shared/Library/Application\ Support/Intel/Licenses.



Resolution : 

Assuming that you have a valid serial number or product license, the solution is to enable write permission for the directory Users/Shared/Library/Application\ Support/Intel/Licenses.

Problem : When I run my code compiled with the Intel Fortran Compiler I get 'sigsegv' on linux (or sigbus on Mac OS X).  This code has run fine for years on <insert your previous compiler/platform>.  Is this a bug with the Intel Compiler?


Environment : linux or Mac OS* X


Root Cause : There are many possible causes.  A segmention fault (bus error Mac OS X) is a general fault that can have multiple causes.  We outline these potential causes below and give suggestions for avoiding the segmentation fault


Possible Cause #1 Fortran Specific Stackspace Exhaustion: Solution, -heap-arrays compiler option.

The Intel Fortran Compiler use stack space to allocate a number of temporary or intermediate copies of array data. 

NON-OpenMP and NON-Auto-parallelized Applications: IF your program is not using OpenMP or Auto-parallelization (-parallel compiler switch) and your compiler is newer than Linux v9.1.037 (or all Mac OS* compilers), try the -heap-arrays compiler option.  OpenMP or Auto-parallelization users and users with Linux compilers older than v9.1.037 please read ahead to Possible Cause #2 for tips on unlimiting the stack size.

-heap-arrays

If this removes the sigsegv or bus error, you may STOP at this point.  You may wish to read the attached PDF presentation (link at bottom of page) to learn about when and where array temporaries are created.  With a few code changes you may be able to avoid some array temporaries, and hence reduce your application's need for temporary copies (improves performance).  Also, the -heap-arrays compiler option can take an optional argument [size] to specify the threshold size in Kbytes at which arrays larger than [size] are allocated on heap, all others on stack.  For example:

-heap-arrays 10

puts all automatic and temporary arrays larger than 10Kbytes on heap


Cause #2 Stackspace Exhaustion.   Solution: Unlimiting Stacksize for OpenMP Applications or any Application:
The first step is to try to increase your shell stack limit on Linux and Mac OS* X.  However, this option can have unwanted effects on data sharing with OpenMP or auto-parallelized code.  Because of this, OpenMP and auto-parallelization users are advised to not use -heap-arrays and insted try to unlimit their shell stack size limit.

Linux, bash:    ulimit -s unlimited
Linux, csh/tcsh:   unlimit stacksize

You may check your stack size limit with:
bash:  ulimit -a
csh:    limit
and look for 'stack size' limit for your shell environment

Notes:  If you run your program under the control of a batch subsystem you may need to add the command above to your user startup files ( ~/.bashrc  ~/.profile  or ~/.cshrc )

For Mac OS* X, there is a hard upper limit on the shell stacksize.  For most systems, this is:

bash:  ulimit -s 65532

which sets the limit to 64Mbytes.

An alternative is to use a linker option to increase the executable's default shell stacksize, as documented here:  http://software.intel.com/en-us/articles/intel-fortran-compiler-increased-stack-usage-of-80-or-higher-compilers-causes-segmentation-fault/

Re-run your application, if this fixes the issue you may stop.  If your application still generates sigsegv or bus error, continue reading.


Possible Cause #3, Stack Corruption Due to User Coding Error. There are a number of user coding errors that can cause stack corruption and lead to a sigsegv or bus error at run time.  These errors are particularly hard to find since the segmentation fault may occur later in the program in a section unrelated to where the stack was initially corrupted.

The first step is to try to isolate where in the code the fault occurs.  This is done by generating an execution 'traceback'.  Compile and link using the ifort driver and these options:

-g -traceback

When the code faults, you will often get a report showing the call stack when the fault occurs.  If you do not get a stack traceback, insure that you have used -g for both compilation and link and make sure that -traceback was used on the compilation.  There are cases where the seg fault occurs while the program is in kernel space and thus no user stack is available for trace back.  We are working to improve this in a future release.

This trace back report is read from the bottom of the list upwards.  Find the uppermost subroutine or function from your code along with it's line number to isolate which instruction caused the fault.  Check for user coding errors at this statement.  If no obvious user error, continue below


Possible Cause #4, exceeding Array Bound.  Solution, try -check bounds

The -check-bounds compiler option provides a run-time check of array accesses and character string expressions to insure that the indices are within the boundaries of the array.  This checking is useful to find cases where the indices go outside of the declared size of the array.  This option has a big impact on performance, the magnitude of which depends on how many array accesses are performed in the application.  Also, -check-bounds array bounds checking is not performed for arrays that are dummy arguments in which the last dimension bound is specified as * or when both upper and lower dimensions are 1.   To enable bounds checking, compile with:

-check bounds -g

and run your program.  The checking is performed at run time and not at compile time.  If this finds your error STOP.  ELSE keep reading.


Possible Cause #5, calling a function as a subroutine, or invoking a subroutine as if it were a function. 

These are user coding errors where a user does something similar to this:

--- main program ---
...
call ThisIsIllegal( some_arguments )
...
--- end main program ---

--- ThisIsIllegal ---
integer function ThisIsIllegal( some_arguments )
...
--- end ThisIsIllegal ---

In the example above, the main program calls ThisIsIllegal as if it were a subroutine, however ThisIsIllegal is declared as a function.  This can cause stack corruption.  To test for these conditions, try using compiler option

-fp-stack-check -g -traceback

compile with these options and run.   If the stack is corrupted by something similar to the above, your code will exit and give a stack trace.

You can check the interfaces of your procedures with a compile time check:

-gen-interfaces -warn interfaces

This compile time check will generate INTERFACE blocks for your procedures.  The -warn interfaces will then use these compiler-generated interfaces and check the calls to your procedures to make sure arguments and interfaces match between caller and callee.   Note that this check occurs only for Fortran source files.  This will not check interfaces in mixed language program.


Possible Cause #6, large array temporaries caused by passing non-contiguous array sections. Solution, detect with -check arg_temp_created and fix with coding change to include explicit interface and assumed shaped arrays.

Consider this 'before' example:

--- main program ---
real(8) :: f(1800,3600,1)
external sub
...
call sub( f(1:900,:,:) )
...
--- end main program ---

and the "sub" subroutine is in a separately compiled source file:
--- external subroutine "sub" ---
subroutine sub( f )
real(8) :: f(900,3600,1)
...
--- end subroutine "sub" ---

In this case, "sub" is expecting a contiguous array of size 900x3600x1.  However, the call is passing an array that is not contiguous in memory.  In situations such as this, the compiler will make an array temporary at the call to copy the elements of the array "f" from non-contiguous chucks into a contiguous array such as what "sub" is expecting.  This temporary is allocated on stack unless -heap-arrays is specified. 

To check if this is occuring in your code, compile with
-check arg_temp_created

and run the program.  Messages will be written when argument temporaries are created.  To work around the issue, creating a explicit interface and using an assumed shaped array in "sub" will remove the need for an array temporary:

--- main ---
real(8) :: f(1800,3600,1)
interface
subroutine sub(f)
real(8) :: f(:,:,:)
end subroutine sub
end interface
...
call sub( f(1:900,:,:) )
...
--- end main program ---

--- "sub" ---
subroutine sub( f )
real(8) :: f(:,:,:)
...
end subroutine sub

Keep in mind, that although this avoids the array temporary, within "sub" the compiler is now aware that the array "f" may be non-contiguous.  Thus, some optimizations on statements using "f" may be disabled and thus affect performance.


Case NONE OF THE ABOVE:  Solution, more in-depth analysis is needed. 

99% of the sigsegv or bus error cases tend to fall into the categories above.  However, there are other cases where segmentation faults can occur. 

If your application is linking in external libraries, make sure that the library is compatible with your compiler.  Was the external library compiled with the Intel Compiler?  If so, were the major versions the same - that is, was the library compiled with Intel Fortran v9.1 but your application built with Intel Fortran v10.x or v11.x?  Intel only guarantees compatibility within major versions ( 9, 10, 11 are examples of major versions). 

If the external library is from a software vendor or tool:  does this vendor explicitly name the Intel Compiler as compatible, and if so, with which version(s) have they verified their library?  You should only use the version(s) of the Intel Compiler certified by your vendor.  If you need an older version of the Intel Compiler, please see How do I get an older version of an Intel(R) Software Development Product.


When all else fails ....

Post a note to the User Forum HERE.   Please include the name of your application if it a commonly available code, post a stack trace (if you can get one), compiler options used, and ideally a tarball of the entire application, input files and instructions on how to run the program.

If you have support for your product, you can open an issue at http://premier.intel.com.

For more background information, try the excellent Dr. Fortran Article "Don't Blow Your Stack!"

And read the PDF presentation attached to this article Fortran Compiler Use of Temporaries: Stack+usage.pdf

Problem : 

During installation, an error message of "Invalid Serial Number" will result if the user does not have write permission to the /tmp directory or the  /Users/Shared/Library/Application\ Support/Intel/Licenses.

Environment : 

Mac OS X, Intel Compiler 9.1, 10.1, 11.0
A related article pertaining to Mac OS X, Intel Compiler 11.1 can be found here.

Root Cause : 

The error "Invalid Serial Number" will appear if the user does not have write permission to the directories /Users/Shared/Library/Application\ Support/Intel/Licenses or /tmp.

These directories by default has write permission enabled, however, installation of other third party products such as Adobe products might change the permission for this directory. This change in permission will result in an error during installation of Intel(R) Compiler Products because the installer can not create a license file in this directory.

Even if the user provide their own license file instead of a serial number, the error will still occur if the installer can not copy the license to the directory /Users/Shared/Library/Application\ Support/Intel/Licenses.

Resolution : 

A more appropriate error message will be issue in version 11.1 of the Intel Compiler Products.  Assuming that you have a valid serial number or product license, the solution is to enable write permission for the directories Users/Shared/Library/Application\ Support/Intel/Licenses and /tmp.

Reference Number : DPD200111543


Version : 11.0


Operating System : All


Problem Description : The compiler gives a syntax error for an array constructor of the form:

(/parameter-name/)

where parameter-name is a PARAMETER constant that has the same name as a datatype keyword (BYTE, INTEGER, REAL, COMPLEX, etc.)  For example:

INTEGER, PARAMETER :: BYTE = 123
INTEGER IA(1)
IA = (/BYTE/)
END

When compiled, this gives an error such as:

example.f90(3): error #5082: Syntax error, found ')' when expecting one of: ( <IDENTIFIER> <CHAR_CON_KIND_PARAM> <CHAR_NAM_KIND_PARAM> <CHARACTER_CONSTANT> <INTEGER_CONSTANT> ...
IA = (/BYTE/)
------------^


Resolution Status : This problem is fixed in the January 2009 product update.  A workaround is to use the Fortran 2003 array constructor syntax:

[parameter-name]

instead.



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]