Reference Number : dpd200049725


Version : 10.0,10.1,11.0,11.1

Product : Intel Fortran Compiler, Professional Edition


Operating System : Linux


Problem Description : 
The Intel Fortran compiler uses an additional, hidden argument to return the result of a function of type COMPLEX. Adding the BIND(C) attribute to the function declaration should cause the result to be returned by value, in accordance with the x64 ABI, so that the function becomes interoperable with the Intel and GNU C compilers. Currently, it does not.

Resolution Status :  This may be fixed in a future version of the Intel compiler



[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 : DPD200138527


Version : 11.1


Product : Intel® Fortran Compiler


Operating System : All

Problem Description : If a derived type is declared containing a UNION, and the type is a SEQUENCE type or is interoperable (BIND(C)), and the UNION contains a misaligned field, the compiler incorrectly adds padding bytes before each misaligned field.

UNION is an extension to the Fortran standard, supported by Intel Fortran, that allows the declaration of overlapping sets of derived type components. A SEQUENCE type is a derived type containing the SEQUENCE keyword. The Fortran standard specifies that components of a SEQUENCE type may not be rearranged by the compiler; in Intel Fortran, SEQUENCE types do not, by default, have alignment padding added before misaligned components. (This can be overridden with the "align sequence" option.) Lastly, an interoperable derived type, declared with the BIND(C) specifier, is required to have its components laid out exactly as the companion C processor would do it - this may involve padding if the C processor would pad by default.

Consider the following declaration:

type :: mytype
  sequence
  integer(2) f1
  union
   map
     integer(2) xa1
     integer(4) xa2
     integer(2) xa3
     integer(4) xa4
   end map
   map
     integer(4) xb1
     integer(2) xb2
     integer(4) xb3
     integer(2) xb4
   end map
  end union
end type mytype

Because the first component, f1, is two bytes long, the UNION starts at offset 2. (Remember that SEQUENCE disables padding in Intel Fortran.) This would make components xa1 and xb1 begin at offset 2, causing xb1 to be misaligned, since 2 is not an integral multiple of its size, 4. Components xa2 and xa3 are naturally aligned and should begin at offsets 4 and 8.  xb2 is misaligned at offset 6.

Because of a defect, the compiler incorrectly inserts padding before each misaligned variable inside the UNION.  The following table shows the offsets for each component, with and without the defect:

Component	With Defect	Correct
f1	0	0
xa1	4	2
xa2	8	4
xa3	12	8
xa4	16	10
xb1	4	2
xb2	8	6
xb3	12	8
xb4	16	12
f2	20	14

Note that f2 is (correctly) misaligned in both cases, and that xb4 received an additional two bytes of padding - the inappropriate padding happens only within the UNION.

Resolution Status : This error will be corrected in a future compiler update.  As a workaround, enclose the TYPE declaration in the following directives:

 

!DEC$ OPTIONS /NOALIGN /NOWARN
... TYPE goes here
!DEC$ END OPTIONS

You can also compile with the "noalign" compiler option.

 

[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 : DPD200121218


Version : 11.0


Operating System : Linux*


Problem Description : Starting with 11.0.081, a fix was made to the compiler driver to link the Intel Math Library libimf statically by default (the intended and documented behavior) instead of dynamically.  If -lm is used with the compiler driver (icc/icpc/ifort), the driver automatically inserts libimf before libm in the link line.  Linking in libimf.a when this is done causes a problem if -lm precedes any user-created objects or libraries.  For example:

icc -lm user1.o user2.o -luser3

Gets converted by the driver to:

ld ... -Bstatic -limf -Bdynamic -lm ... user1.o user2.o -luser3 ...

On Linux, static libraries must come after the object/library files that use them in the link line in order for the symbols to resolve.  Since libimf.a comes before the objects/libraries that use standard math functions, these math functions won't resolve to the static Intel math library.  However, the dynamic libm doesn't have an order dependency because it is a dynamic library, so the math functions will resolve to the GNU math library.  This can have a significant performance impact.


Resolution Status : Starting with 11.1.056, the compiler now emits a warning if -lm precedes other user objects or libraries on the linker command line.  If you run into a performance regression between compilers prior to 11.0.081 and compilers from 11.0.081 on, please verify that you don't have -lm being used prior to your objects/libraries in your link lines if you use icc/icpc/ifort to link. Using the above example, make the following change:

icc user1.o user2.o -luser3 -lm

[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 : DPD200119846


Version : 
Intel® C++ Compiler for Linux*and Windows*, 11.1 initial releases and update 1
Intel® Fortran Compiler for Linux*and Windows*, 11.1 initial releases and update 1


Operating System : Microsoft Windows XP*, Microsoft Windows Vista*, Microsoft Windows Server 2003*; Red Hat Enterprise Linux* 3, 4, 5, SUSE LINUX Enterprise Server* 9, 10, 11, other supported Linux distributions (see Release Notes)


Problem Description :  Thread affinity compiler switches /Qpar-affinity (Windows*) or -par-affinity (Linux*) are used to specify compiled-in thread affinity of the executable.  However, when the executable is run, no effect is observed.  In other words, the default runtime thread affinity is used, or if KMP_AFFINITY has been set, the runtime thread affinity matches its setting (the switches are supposed to take precedence).


Resolution Status : The issue has been resolved in the 11.1 update 2 release.  The compiler builds are:
Linux* C++: l_cproc_p_11.1.056
Linux* Fortran: l_cprof_p_11.1.056
Windows* C++: w_cproc_p_11.1.046
Windows* Fortran: w_cprof_p_11.1.046



[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 :  DPD200137886


Version :  11.1


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


Problem Description : 

Improvements in the Intel C++ and Fortran 11.1 release compiler drivers cause each (ifort, icpc, icc) to issue error #10236 for any detected missing files; however, each driver fails to exit accordingly after issuing this "fatal" class of diagnostic.

Here is an example of the diagnostic issued:

            icpc: error #10236: File not found: 'libsubCPP.so'


This resulting behavior causes the compiler driver to incorrectly engage the link phase, which causes residual corruption of the Linux shared library (or DSO) when using the Linux linker (ld) -soname option with the compiler driver to create a shared library.

When using the Intel compiler to create a shared library, linker options must be passed using the -Wl or -Xlinker option. The latter requires special handling of any linker options that themselves take arguments.

In the case of supplying the linker -soname option, users must ensure the correct syntax is used with -Xlinker.

The incorrect syntax is: -Xlinker -soname <name>

The correct syntax is one of two forms:

-Xlinker -soname=<name>

-OR-

-Xlinker -soname -Xlinker <name>

Where <name> represents the name argument to -soname and name assigned to the shared library’s internal DT_SONAMEfield.

When the incorrect syntax indicated above is used, the compiler issues the compilation error #10236, removes the "<name>" argument, and then incorrectly engages the link phase to create the shared library, but it provides only the -soname option with no <name> argument. It is unknown to the user the resulting shared library contains an invalid embedded DT_SONAME. This invalid DT_SONAME can cause subsequent confusing linking issues such as unresolved externals when using the shared library, and/or confusing output from the ldd utility.

The details below show how each compiler driver (icc, icpc, ifort) is susceptible to this defect and the incorrect DT_SONAME each can embed into a shared library. What is embedded in the DT_SONAME field is influenced by the order options appear on the compiler command line. Additionally, the details show how each compiler creates a valid shared library when the correct form of the -soname option is used with -Xlinker.

 

Invalid command line:icpc issues error and embeds invalid SONAME

$ icpc -V -shared -Xlinker -relax -Xlinker --whole-archive libsubCPP.a -Xlinker --no-whole-archive -o ./libsubCPP.so -Xlinker -soname libsubCPP.so
Intel(R) C++ Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cproc_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
icpc: error #10236: File not found: 'libsubCPP.so'

GNU ld version 2.17.50.0.6-5.el5 20061020

$ objdump -x libsubCPP.so | grep SONAME
SONAME -L/opt/intel/compiler/cpro/Compiler/11.1/046/lib/intel64


Valid command line:icpc issues no error and embeds valid SONAME

$ icpc -V -shared -Xlinker -relax -Xlinker --whole-archive libsubCPP.a -Xlinker --no-whole-archive -o ./libsubCPP.so -Xlinker -soname=libsubCPP.so
Intel(R) C++ Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cproc_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

GNU ld version 2.17.50.0.6-5.el5 20061020

$ objdump -x libsubCPP.so | grep SONAME
SONAME libsubCPP.so


Invalid command line:icc issues error and embeds invalid SONAME

$ icc -V -shared -Xlinker -relax -Xlinker --whole-archive libsubC.a -Xlinker --no-whole-archive -o ./libsubC.so -Xlinker -soname libsubC.so
Intel(R) C Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cproc_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
icc: error #10236: File not found: 'libsubC.so'

GNU ld version 2.17.50.0.6-5.el5 20061020

$ objdump -x libsubC.so | grep SONAME
SONAME -L/opt/intel/compiler/cpro/Compiler/11.1/046/lib/intel64


Valid command line:icc issues no error and embeds valid SONAME

$ icc -V -shared -Xlinker -relax -Xlinker --whole-archive libsubC.a -Xlinker --no-whole-archive -o ./libsubC.so -Xlinker -soname=libsubC.so
Intel(R) C Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090630 Package ID: l_cproc_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

GNU ld version 2.17.50.0.6-5.el5 20061020

$ objdump -x libsubC.so | grep SONAME
SONAME libsubC.so


Invalid command line:ifort issues error and embeds invalid SONAME

$ ifort -V -shared -Xlinker -relax -Xlinker --whole-archive libsubF.a -Xlinker --no-whole-archive -o ./libsubF.so -Xlinker -soname libsubF.so
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.
ifort: error #10236: File not found: 'libsubF.so'

GNU ld version 2.17.50.0.6-5.el5 20061020

$ objdump -x libsubF.so | grep SONAME
SONAME -L/opt/intel/compiler/cpro/Compiler/11.1/046/lib/intel64


Valid command line:ifort issues no error and embeds valid SONAME

$ ifort -V -shared -Xlinker -relax -Xlinker --whole-archive libsubF.a -Xlinker --no-whole-archive -o ./libsubF.so -Xlinker -soname=libsubF.so
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.

GNU ld version 2.17.50.0.6-5.el5 20061020

$ objdump -x libsubF.so | grep SONAME
SONAME libsubF.so

Resolution Status :  This is a known issue that will be fixed in a future release. To resolve the issue, modify any usage of the -Xlinker option with -soname to ensure the correct syntax of the -soname option is used.



[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.]