Intel Software Network articles feed

Error : Failed to enable trusted storage check for licensing

Tue, 10 Nov 2009 16:38:05 -0800

Problem :
When using the compiler you see the following error message

"error #10310: Failed to enable trusted storage check for licensing: Warning" Enable Trusted Storage failed (flexnet error code 20). Trusted Storage based licence could "

Environment :
Intel(R) 64 , Windows* 7

Root Cause :
Service “FLEXnet Licensing Service 64” can not be installed by non-administrator users on Windows 7.

Workaround:

Run icl as administrator once.

Steps:
1. Go to start -> All Programs -> Intel(R) Software Development Tools -> Intel(R) C++ Compiler Professional 11.1.0xx > C++ Build Environment for application running on Intel(R) 64
2. run command:

runas /user:administrator "icl /v"

You will be prompted to input administrator’s password. This step will trigger icl to install the Windows service “FLEXnet Licensing Service 64”.

Intel® Professional Edition Compilers 11.1 Fixes List

Thu, 05 Nov 2009 13:37:23 -0800

NOTE: Defects and feature requests described below represent specific issues with specific test cases. It is difficult to succinctly describe an issue and how it impacted the specific test case. Some of the issues listed may impact multiple architectures, operating systems, and/or languages. If you have any questions about the issues discussed in this report, please post on the user forums, http://software.intel.com/en-us/forums or submit an issue to Intel Premier Support, https://premier.intel.com. The fixes list for Intel® IPP Library 6.1 can be found here.

Update 3 (Posted October 2009), Package IDs below

l_cproc_p_11.1.059
l_cprof_p_11.1.059
m_cproc_p_11.1.076
m_cprof_p_11.1.076
w_cproc_p_11.1.051
w_cprof_p_11.1.051

DPD200005308	Fortran	Access violation with OpenMP and debug option enabled
DPD200012215	C, C++, Fortran	documentation about application register access is vague
DPD200021013	C, C++	compiler mistakenly assumes all sources compiled with same set of options
DPD200033150	Fortran	Slow compile
DPD200038801	Fortran	Incorrect Static Verifier error message 12224
DPD200039280	Fortran	Static Verifier produces invalid warning for optional Fortran argument
DPD200048138	Fortran	Invalid Debug Information message shown for DLLIMPORTed COMMON variables
DPD200049461	C	Bogus error #12048 on safe negative index
DPD200049575	C++	bogus error #12178 on used local const with -diag-enable sv3
DPD200049579	C++	Static Verifier:incorrect error
DPD200082641	Fortran	READ statement doesn't return correct completion status
DPD200082921	Fortran	Access violation in case the malloc from C code is used to allocate the memory
DPD200083739	C	Incorrect variable substitution during optimization cross branches
DPD200085342	C	internal error - backend signals on both Linux and Windows version of 11.1
DPD200085556	Fortran	iidb uses 100% of CPU while waiting for input
DPD200085613	C	icc don't accept --exclude-libs linker flag
DPD200110443	Fortran	UNROLL_AND_JAM directive ignored or not working as expected on triple-nested DO-LOOP
DPD200110916	C++	Microsoft and Gnu compatibility on allowing pure virtual specifiers in prototype instantiations
DPD200112090	Fortran	Incorrect pointer with OpenMP at -O0
DPD200118525	Fortran	Visual Studio Project: Source Code Control glyphs not automatically updated
DPD200119954	Fortran	demo default startup project not correct
DPD200121416	C++	Profile Guided Optimization: 12% performance drop
DPD200136609	Fortran	Loop distribution caused Incorrect results when using ifort -i8 -r8 -openmp
DPD200136761	C++	Optimizer not disambiguating memory as well, leading to more memory accesses then in 11.0
DPD200136823	C++	#pragma disable does not disable first instance of #pragma outside of code block
DPD200136891	Fortran	Problem with using dynamically allocated arrays in OpenMP reduction clause
DPD200136984	Fortran	MKL library for wrong calling convention gets linked on command line
DPD200136996	C++	(0): internal error: backend signals
DPD200137044	C++, C	Linux: wint_t not defined in stddef.h
DPD200137266	C++	problem with template dependent name processing and default params
DPD200137318	C, C++	/Qprof-psa-* options should be removed from /help
DPD200137464	Fortran	Internal compiler error (C0000005)
DPD200137508	Fortran	Run-Time Library: error on namelist for internal file write
DPD200137584	Fortran	-fpe0 and -fltconsistency interaction
DPD200137763	C, C++	Incorrect error when building with -diag-enable sc-parallel
DPD200137967	Fortran	Link error for already defined (duplicate) symbol with type-bound procedures and /Od
DPD200138038	Fortran	Incorrect name decoration for EQUIVALENCEd module symbols
DPD200138085	Fortran	Procedure pointer component and debug symbols cause internal compiler error or CPU-bound compilation
DPD200138089	Fortran	Debugger shows wrong value for component of polymorphic type
DPD200138527	Fortran	SEQUENCE type adds padding before UNION
DPD200138674	Fortran	Internal Compiler Error when accessing an overloaded interface
DPD200138694	Fortran	Internal compiler error involving type bound procedure
DPD200138746	Fortran	Nested derived type with POINTER causes internal compiler error in Loop Multiversioning
DPD200138828	C, C++	internal error: 0_1561
DPD200138845	Fortran	Compiler hang at exiting from compilation error.
DPD200138870	Fortran	Feature Request: -opt-report should report COMMON blocks splitting (which can happen with -ipo)
DPD200138937	Fortran	-ftrapuv does not catch divide-by-zero in Where clause with real array size < 8, and incorrect behavior for array size >= 8
DPD200138944	Fortran	IMPLICIT NONE gives error for contained procedure argument that is CALLed
DPD200139029	Fortran	STOP 0 in Windowing application results in Error 38 to CONOUT$
DPD200139383	C, C++	Regression with libirc_s.a, ld duplicated symbol error
DPD200139390	C	internal compiler error on 64-bit code in linux kernel
DPD200139418	C++	error #409: "T2::T2()" provides no initializer for: const member "T2::t1"
DPD200139432	C, C++	"internal error: 0_1149" when using /fp:fast
DPD200139458	C++	ICC can't compile file due to friend class declaration with nontype template argument
DPD200139473	Fortran	"/debug:parallel" is not added to the command line for Fortran when /Zi selected
DPD200139530	Fortran	Internal Compiler Error when routine called with derived type argument inside ASSOCIATE construct
DPD200139531	Fortran	Internal Compiler Error with /Qfp-stack-check on Intel64
DPD200139541	C, C++	assertion failure with overloaded function call and using declaration in dependent name processing
DPD200139555	Fortran	IPO link invokes ld twice, the first instance generates "ld: no input files" failure
DPD200139577	C++	backend signals internal compiler error at -O2
DPD200139608	Fortran	ENDFILE gives error for stream access file
DPD200139624	C++	(0): internal error: backend signals in termination test in openmp iterator loop
DPD200139640	C++	template argument deduction problem with const template operator
DPD200139696	Fortran	Parsing error for variable named PROCEDURE
DPD200139700	Fortran	Dummy argument mismatch error for passed procedure with CLASS(*) argument
DPD200139701	Fortran	Internal compiler error for pointer assignment to type-bound procedure
DPD200139745	Fortran	Internal compiler error for call passing class(*) object and procedure
DPD200139785	Fortran	FPP: Comment appearing between fpp directives causes incorrect parsing of #ifdef directive
DPD200139935	C, C++	Internal error: backend signals
DPD200139947	Fortran	Internal compiler error: segmentation violation signal raised
DPD200139986	Fortran	Internal Compiler Error during High Level Optimization while compiling at O3 but not at O2, regression in 11.1.046
DPD200140001	Fortran	VS2008 throws External component has thrown an exception error when creating new Fortran project
DPD200140037	Fortran	Seg Fault after Mem-op Detection optimization phase
DPD200140069	Fortran	Internal Compiler Error when compiling with 11.1 versions, not with 11.0.074
DPD200140117	Fortran	Possible infinite loop or memory leak at compilation time in Loop fusion
DPD200140128	Fortran	FPP: Fundamental confusion with fpp and macro expansion leads to #error: '#ifdef' argument starts with wrong symbol.
DPD200140234	Fortran	Internal Compiler Error with Mac OS 11.1.067 compile
DPD200140243	Fortran	Internal Compiler Error at -O2 or higher on IA-32, no error on Intel 64 but no loop vectorization
DPD200140550	C	Internal compiler error in Code Generator

Update 2 revised (Posted October 2009), Package IDs below

w_cproc_p_11.1.048
w_cprof_p_11.1.048

DPD200139120 C, C++, Fortran - The packages were rebuilt to correct an issue where the compiler would not run on certain Windows 7* and Windows Server 2008* systems. Correctness of the generated code is not an issue.

Update 2 (Posted September 2009), Package IDs below

l_cproc_p_11.1.056
l_cprof_p_11.1.056
m_cproc_p_11.1.067
m_cprof_p_11.1.067
w_cproc_p_11.1.046
w_cprof_p_11.1.046

DPD200003663	C, C++	Access mechanism inconsistency for #pragma section()/__declspec(allocate()) problems.
DPD200007737	Fortran	HLO causes incorrect results only with Intel® Core™ Duo processor and 32 bit version of compiler
DPD200017249	C	Linux* kernel: Feature Request: support __builtin_trap intrinsic
DPD200022129	C	O2 problem
DPD200022902	C, C++, Fortran	wrong compiler annotation with -prof_use
DPD200032138	C, C++	Regression in 10.0 auto-parallelizer
DPD200041387	C++	Performance regression with 11.0 Beta compiler at -O3 -ipo PGO.
DPD200042107	C, C++	compile time 100x Microsoft Visual C++ 7.0 - long optimization time
DPD200045100	C	IDB fails to load executable - libthread_db.so.1 undefined symbol ps_lgetfpregs
DPD200048386	Fortran	Procedure pointers are not distinct from integers in TKR signature resolution
DPD200048780	Fortran	Incorrect address handed to C-Fortran interoperable function
DPD200048863	Fortran	ifort 11.0 BIND(C,name="") produces object files with empty symbol names
DPD200049434	C++	Bogus warning #12174 on a function declared noreturn
DPD200050515	C++	Compiler Intrinsic missing from header file and documentation
DPD200050739	C, C++	symbol info reload performance unacceptable for large applications
DPD200051151	Fortran, C++, C	FLEXlm server fails to start on Windows* Server 2008 x64
DPD200083317	Fortran	Array constructor [,,] is not thread safe
DPD200083894	Fortran	Custom build step feature doesn't work in case there are specific symbols in the pathname
DPD200084262	C	stack run time check reports failure for alignment greater than 64
DPD200111195	Fortran	RANDOM_NUMBER is not threadsafe
DPD200111308	C++	Cannot specify sets of OS procs with {} in proclist with KMP_AFFINITY=explicit
DPD200111309	C, C++, Fortran	Need consistent correspondence between OMP hread ids and global thread ids in non-nested code
DPD200111314	C, C++, Fortran	Error initializing foreign thread's OMP affinity mask
DPD200112213	Fortran	OpenMP causes seg fault with contains subroutine
DPD200117988	Fortran	11.1 beta get segmentation fault
DPD200118875	Fortran	ifort 11.0 benchmark fails to validate on IA-64
DPD200119435	C	Need PIC version of libimf.a
DPD200120466	C	Unix (gcc feature not in icc): missing many chk __builtin___ rouitines
DPD200120952	C++	OpenMP task crashes with new class statement in Debug mode
DPD200121133	C	Resulting generated code gets different results with -O2 and -O3
DPD200121218	C, C++, Fortran	linking -lm before objects calling math functions results in GNU libm math functions being used instead of Intel libimf functions
DPD200121498	Fortran	Local array with allocatable components not deallocated on routine exit
DPD200135534	Fortran	ifort mainline lost optimization of product reduction
DPD200135655	C++	Compiler packaging error when installed by non-root user
DPD200135696	C	unresolved symbol with /Qipo in 11.x only - 10.x works
DPD200135929	C++	Software Pipelining causes runtime segmenation fault.
DPD200135962	Fortran	Correct test with allocatable character array produces SegV.
DPD200135966	C++	icc warning level is incompatible with vc warning level
DPD200135967	C++	Code Generator SCH Postpass cause memory ambiguation.
DPD200136024	C++	runtime segmentation fault in PGO + IPO build.
DPD200136315	C++	Slow compile time - icc 11.1 average 2.7x slower than gcc3.4
DPD200136339	C	icc takes too long to compile a .c file
DPD200136540	C	runtime crash when /Qnum-opt 25
DPD200136675	C	icc 11.1 generates code that has a reference to __moddi3
DPD200136711	C++	gcc compatibility - diff in priority of -I and -isystem
DPD200136754	C, C++	icc unable to find framework include when isysroot is set
DPD200136776	C++, C	"(0): internal error: 0_0" with multi-source compilation
DPD200136806	Fortran	Can't set large values for REAL*8 in tooltips
DPD200136846	C++	icpc fails to compile the test case with --permissive
DPD200136852	C++	icpc, g++ 4.3.0 and __builtin_isfinite
DPD200136877	Fortran	Error for pointer assignment of ASSOCIATE name for dummy argument of PURE subroutine
DPD200136885	Fortran	Implicit typing happens in the wrong scope
DPD200136909	C++	Optimization generates incorrect code
DPD200136951	C++	0x5C Japanese Character Issue
DPD200136972	Fortran	Error with ALARM-Portability Function.
DPD200137145	Fortran	Deferred-length character should not require /assume:realloc_lhs
DPD200137215	Fortran	Variable name CLASS confuses parser
DPD200137216	Fortran	Regression - typing floating point expression into debugger Watch window crashes Microsoft Visual Studio*
DPD200137220	Fortran	Customers report .F and .FOR files appear as free-form source in Visual Studio text editor as of 11.1
DPD200137276	C++	Code generation problem
DPD200137279	Fortran	Internal Compiler Error with /gen-interfaces
DPD200137347	Fortran	IFORT does not accept derived type name starting with "is"
DPD200137404	C, C++, Fortran	Installation stalls at license agreement on MAC 11.1
DPD200137410	Fortran	/fpscomp:filesfromcmd does not work if null argument provided.
DPD200137424	Fortran	No code generated for call to elemental type-bound procedure with no arguments
DPD200137428	Fortran	Internal Compiler Error with 11.1.038
DPD200137453	Fortran	File ACTION='READWRITE' does not allow second process to open file for writes
DPD200137485	Fortran	Error: for_array_copy_in/for_array_copy_out again
DPD200137518	Fortran	Conflicting attributes error for protected allocatable character
DPD200137527	C, C++	icc does not accept -Wstrict-aliasing=2
DPD200137545	C, C++	Linux kernel: icc emits undefined symbol, while gcc doesn't
DPD200137552	Fortran	internal compiler error (C0000005)
DPD200137598	Fortran	Incorrect results at -O3 with specific optimization
DPD200137625	Fortran	Assignment of array constructor to allocatable array component does not reallocate left side
DPD200137666	C	Regression test suite fails with icc 11.0, 11.1 but is fine with 10.1 and earlier versions
DPD200137681	Fortran	Problem with 2-byte characters in NAMELIST input data when using static debug libraries
DPD200137687	Fortran	Error #10106 for valid code
DPD200137715	Fortran	Concatenation of deferred-length character component of derived type gives garbage result
DPD200137735	C++, C	String layout on Mac OS X* Leopard/Snow Leopard for 64-bit
DPD200137781	C++	Need scalar var privatization support for std::complex data type with func call
DPD200137862	Fortran	Format compiles incorrectly
DPD200137880	C++, C	driver link in libirc.a twice resulting in duplicated symbols at link time
DPD200138020	Fortran	Wrong executing results after compiling
DPD200138029	Fortran	ifort linux Intel 64 11.1.046 Internal Compiler Error
DPD200138035	C++	icc produces bad x86_64 Mach-O relocation entries
DPD200138042	Fortran	write routine is consuming all of memory and crashing the system
DPD200138087	Fortran	Assignment of derived type with allocatable scalar and type-bound procedure causes access violation
DPD200138144	C, C++	ipo build reports unresolved ___builtin_object_size symbol
DPD200138343	C, C++	"(0) internal error: backend signals" with openmp on "while"
DPD200138406	C, C++, Fortran	Shared libraries flagged as needing executable stacks prevents being loaded when SELinux enabled
DPD200138415	Fortran	Bad debug information for Fortran array variable
DPD200138447	C	Executing wrong code path at O2
DPD200138449	Fortran	ifort 11.1 internal compiler error on module with recursive subroutine containing CLASS pointer
DPD200138493		OSR: illigal SIGN extend removal around UNSIGNED value in strength reduction
DPD200138568	Fortran	vec-report3 or 4 or 5 on 11.1 Mac OS X* Compiler Pro causes bogus DWARF error
DPD200138583	C	internal compiler error: Creating constant of incorrect size
DPD200138584	C	assertion in compiler
DPD200138607	Fortran	Internal compiler error during compile of large source file under 11.1 compilers
DPD200138609	C++	Compiler fails to select correct template function
DPD200138632		Code coverage with unwind handler
DPD200138634	Fortran	OpenMP directive causes internal compiler error with ifort 11.1.046
DPD200138649	Fortran	incorrect debug info for subroutine array parameter
DPD200138652	Fortran	Internal compiler error related to multifaceted derived type structures
DPD200138663	C++	Compiler Error: Gnu-style asm must use __asm__ keyword when -use_msasm is specified
DPD200138665	Fortran	internal read not working with 11.1
DPD200138738	C, C++	ICC not differentiating between USER_HEADER_SEARCH & HEADER_SEARCH paths
DPD200138791	Fortran	Inlining a subroutine containing an OpenMP parallel region destroys associated status of pointer argument
DPD200138893	Fortran	Memory leak on assignment of derived types with allocatable components
DPD200138899	Fortran	MAXLOC intrinsic bug on IA-64 processor
DPD200138901	Fortran	Internal compiler error at -O3 but not -O2 for 11.1.046
DPD200138938	Fortran	ifort 11.1 -debug internal compiler error on module with procedures bound by name
DPD200139006	C++	Error during project conversion
DPD200139120	C, C++	the application hang due to xgetbv in __intel_cpu_indicator_init()

* Other names and brands may be claimed as the property of others.

Intel Fortran Compiler 11.1 Release Notes

Thu, 22 Oct 2009 12:49:09 -0700

This page provides the current Installation Guide and Release Notes for the Intel® Fortran Compiler products. All files are in PDF format - Adobe Reader* (or compatible) required. Japanese translations are provided at even-numbered updates.

11.1 Update 3, October 2009

Intel® Fortran Compiler Professional Edition for Linux*

English

Intel® Fortran Compiler Professional Edition for Mac OS X*

English

Intel® Visual Fortran Compiler Professional Edition for Windows*

English

11.1 Update 2 (Revised), October 2009

Intel® Visual Fortran Compiler Professional Edition for Windows*

English

11.1 Update 2, September 2009

Intel® Fortran Compiler Professional Edition for Linux*

Intel® Fortran Compiler Professional Edition for Mac OS X*

English

Intel® Visual Fortran Compiler Professional Edition for Windows*

For questions or technical support, visit Intel® Software Developer Support

Incorrect padding added for SEQUENCE or BIND(C) type with UNION

Fri, 16 Oct 2009 12:19:30 -0700

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

Putting -lm Before User Objects/Libraries on Link Line Can Impact Performance

Wed, 14 Oct 2009 11:45:33 -0700

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

Run-Time Error 408 when optional character argument omitted

Mon, 05 Oct 2009 13:24:37 -0700

Reference Number : DPD200140203

Version : 11.1

Operating System : All

Problem Description : The following program has a routine "wrapper" that accepts an optional character argument "s" where "s" is declared with a fixed length. It then passes "s" to a second routine where the argument is also declared as optional. The main program calls "wrapper" with the argument omitted.

program omitted

call wrapper

contains

subroutine wrapper (s)
character(10), optional :: s

call doit (s)
end subroutine wrapper

subroutine doit (s)
character(10), optional :: s

if (present(s)) then
  print *, s
else
  print *, 'S not passed'
end if
end subroutine doit
end program omitted

When the program is compiled with bounds checking enabled (/check:bounds on Windows*, -check bounds on Linux* and Mac OS*), the program gets an inappropriate run-time error similar to the following:

forrtl: severe (408): fort: (18): Dummy character variable 'S' has length 10 which is greater then actual variable length 0

Resolution Status : This issue will be resolved in a future update to the Intel Fortran compiler. A workaround is to declare the dummy argument in the "wrapper" routine as CHARACTER(*) rather than with a fixed length. This is a preferred coding style as using a fixed length can lead to unexpected run-time behavior if the actual argument is too small.

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

Catastrophic error: could not open source file "gmmintrin.h"

Fri, 25 Sep 2009 09:13:49 -0700

Reference Number : DPD200140118

Version : 11.1

- Intel C++ and Fortran Compiler for Linux* 11.1
- Intel C++ and Fortran Compiler for Mac OS* X 11.1
- Intel C++ and Visual Fortran Compiler for Windows* 11.1

Operating System :

Linux*, Mac OS* X, Windows*

Problem Description :
The documentation in the 11.1 update2 compiler says the header file for Intel® AVX intrinsics is "gmmintrin.h". It is wrong.

If you use it, you will get following compile error:

>>icl /c /Od /EHsc t.cpp
Intel(R) C++ Compiler Professional for applications running on IA-32, Version 11.1 Build 20090903 Package ID: w_cpro
_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

t.cpp
t.cpp(3): catastrophic error: could not open source file "gmmintrin.h"
#include
^

compilation aborted for t.cpp (code 4)

Resolution Status :

This is a known bug. It will be fixed in the future compiler update.

Please use the correct header file "immintrin.h".

Thread affinity compiler switches have no effect

Thu, 24 Sep 2009 10:39:53 -0700

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

Error 6405 with interface checking and EXTERNAL declaration in module

Mon, 31 Aug 2009 13:36:12 -0700

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:

A procedure (subroutine or function) is declared with an implicit interface (just a type and/or EXTERNAL) in a module.
A program unit USEs the module and calls the procedure twice or more.
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.]

Intel® compiler error #10236 issued when using -soname corrupts resulting shared library on Linux

Fri, 21 Aug 2009 14:17:04 -0700

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

The correct syntax is one of two forms:

-Xlinker -soname=

-OR-

-Xlinker -soname -Xlinker

Where 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 "" argument, and then incorrectly engages the link phase to create the shared library, but it provides only the -soname option with no 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.]