 


Intel C/C++ Compiler for Win32 Systems
Version 2.4 P98012
Release Notes

Contents

Introduction
User's Guide Addenda
What's New / Fixed Defects
Known Defects
Limitations and Tool Notes
Technical Support and Customer Feedback

Introduction

This document includes late-breaking information not found in the Intel C/C++ Compiler User's Guide for Win32 Systems.  It also lists known defects, as well as limitations and notes related to using the Intel C/C++ Compiler for Win32 Systems Version 2.4 with other tools.  Finally, it includes instructions on how to get technical support or provide feedback for the compiler.

For the most current information on the Intel C/C++ Compiler, visit the Intel Developer's Insight web site at the following URL:

	http://developer.intel.com/

User's Guide Addenda

The following information did not make it into the Intel C/C++ Compiler User's Guide for Win32 Systems.

New Options

Support for the following options is not documented in the User's Guide: 

	To speed program execution, the Intel C/C++ Compiler may change floating point division computations into multiplication by the reciprocal of the denominator.  This change may alter the results of floating point division computations slightly.  You can disable this optimization by using the -Qprec_div option.

	The Intel C/C++ Compiler can be used with Microsoft Visual C++ Version 4.x or 5.0.  The installation program automatically adds the -Qvc5 option to the PERFORM\BIN\icl.cfg file if Microsoft Visual C++ 5.0 is being used.  The -Qvc5 option enables interoperability with Visual C++ 5.0.  When the compiler is used with Visual C++ 4.x, the -Qvc5 option is not used.

	The Intel C/C++ Compiler supports the -GT option.  This option, which enables fiber-safe thread local storage, was added in Version 4.2 of Microsoft Visual C++.

Overriding the Compiler Selected in the Intel Compiler Selection Tool

The Intel C/C++ Compiler plug-in provides support to override the compiler selected in the Intel Compiler Selection Tool.  Using this feature allows one to force the use of either the Intel C/C++ Compiler or the Microsoft Visual C++ Compiler for selected files, while building most of the files in a project using the compiler that was selected in the Intel Compiler Selection Tool.

The feature is activated using special preprocessor macros.  These macros have a special meaning to the Intel C/C++ Compiler plug-in.  Adding one of these macros to the build settings for a file will override the currently selected compiler and force compilation with the specified compiler.  The macros and their meanings are as follows:

		Special Macro				Meaning
		_USE_INTEL_COMPILER		use Intel C/C++ for selected files
		_USE_NON_INTEL_COMPILER		use Microsoft C/C++ for selected files

To use these macros in the Microsoft Developer Studio, follow these steps:

1.	Open a C/C++ project.
2.	Open the "Project Settings" dialog box.
3.	In the "Project Settings" dialog, select the configuration to effect in the "Settings For" list.
4.	Select the file(s) you wish to modify.
5.	Click on the C/C++ tab.
6.	In the C/C++ tab, select General from the Category drop-down list.
7.	In the "Preprocessor definitions" edit box, add the _USE_INTEL_COMPILER macro to force the use of the Intel C/C++ Compiler for the selected file(s).  Add the _USE_NON_INTEL_COMPILER macro to force the use of the Microsoft Visual C++ Compiler for the selected files.

NOTE: In the Build Output, the names of files compiled using one of these special macro definitions will be preceded by the commandline name of the compiler used for compilation.

Default value for _MSC_VER Preprocessor Macro

The Microsoft Visual C++ Compiler sets the _MSC_VER preprocessor macro to a predefined value based on the version of the compiler being used.  To support source code which depends on the value of the _MSC_VER macro, the Intel C/C++ Compiler sets this macro equal to a value corresponding to the version of Visual C++ that is installed when the Intel C/C++ Compiler is installed.  This is done using the Intel C/C++ Compiler configuration file.

For Visual C++ Version 4.x, the PERFORM\BIN\icl.cfg configuration file contains one of the following options:

		Visual C++ Version		Option
		4.0				-D_MSC_VER=1000
		4.1				-D_MSC_VER=1010
		4.2				-D_MSC_VER=1020

For Visual C++ Version 5.0, the -Qvc5 option is used instead.  This option enables interoperability with Visual C++ 5.0 header files and libraries, and defines _MSC_VER=1100. 

Additional Information on MMXT Technology Intrinsics

The following correction and additional note did not make it into the User's Guide:

	On page 12-1, the first sentence of the first paragraph should read "The Pentium II and Pentium processors with MMXT technology include extensions for multimedia programming."

	Also on page 12-1, the following information should be added to the third paragraph:

		In general, after a region of code that contains any reference to an __m64 object (with or without the use of an intrinsic), and before any subsequent use of the floating point state, you must be careful to use the _m_empty intrinsic to empty the multimedia state.  This may occur across function boundaries.  For more information on using MMX technology and floating point, consult the Intel Architecture MMX Technology Programmer's Reference Manual listed in the "Related Publications" section of the Intel C/C++ Compiler User's Guide for Win32 Systems.

What's New / Fixed Defects

Intel releases updates to the Intel C/C++ Compiler Version 2.4 periodically.  Below is a history of the defects fixed with each update, as well as noteworthy changes for each update.  Remaining defects in the Intel C/C++ Compiler are described in the "Known Defects" section below.

Version 2.4 P98012:
The following are changes since the previous update:

	The Intel C/C++ Compiler now supports precompiled header (PCH) files on Windows 95; previously PCH files were only supported on Windows NT.  [trk4467]

	The Intel C/C++ Compiler now allows and ignores the redefinition of default template parameters.  [trk4798]

	The Intel C/C++ Compiler supports generation of source browser files (.SBR files), by invoking the Microsoft Visual C++ Compiler to generate the .SBR file whenever source browser file generation is requested.  The Intel C/C++ Compiler is still used for source compilation in this case.  [trk5158]

	The Intel C/C++ Compiler now supports the cmovz instruction in inline assembly.  [trk5508]

	The Intel C/C++ Compiler now correctly handles initialization of a struct members or array elements of type bool by brace-enclosed initializer lists.  [trk5535]

	The Intel C/C++ Compiler now properly supports the cmpxchg8b instruction in inline assembly.  [trk5547]

Version 2.4 P97241:
The following are changes since the previous update:

	The Intel C/C++ Compiler expands a preprocessor macro that is used as a file name argument to the hdrstop pragma.  [trk4924] 

	The Intel C/C++ Compiler allows redefinition of a pointer-to-enum type in C.  [trk4813] 

	In inline assembly, the effective address of a label can be loaded.  Previously, if a program contained inline assembly that loaded the effective address of a label, the program would fail to link.  [trk4806] 

	The Intel C/C++ Compiler now correctly handles source files specified using a UNC network path (a path beginning with \\).  [trk4800] 

	The Intel Linker Driver program, xilink.exe, now accepts the /lib option and invokes the Micosoft 32-bit Library Manager, lib.exe.  [trk4707] 

Version 2.4 P97176:
This was the initial release of the Intel C/C++ Compiler Version 2.4 product.

Known Defects

The following are known defects in the Intel C/C++ Compiler, which might be fixed in a future version.  This list is divided into defects that can affect both C and C++, and defects that affect only C++ programs.  Where relevant, the behavior of the Intel C/C++ Compiler is compared against the behavior exhibited by the Microsoft* Visual C++* Compiler.

Defects Affecting C and C++ Programs

	If a self-referential macro is used in an argument to another macro, the self-referential macro can be expanded more times by the Intel C/C++ Compiler than by the Microsoft Visual C++ Compiler.

	Here is a program that demonstrates the problem described in this note:

		int a = 42;
		#define a		-a
		#define b(x)	x
		#define c(x)	b(x)
		#define d		c(a)

		void main(void)
		{
		    printf("%d\n", d);
		}

	When this program is compiled with the Intel C/C++ Compiler and executed, it prints 42 because the d parameter in main expands to - -a.  When this program is compiled with the Microsoft Visual C++ Compiler and executed, it prints -42 because the d parameter expands to -a.  [trk2630]

	The Intel C/C++ Compiler does not allow initialization of an unsigned short array with a wide character literal string when the string is cast to unsigned short *.  The following code fragment fails to compile with the Intel C/C++ Compiler for this reason:

		struct {
		    unsigned short buf[32];
		} s = { (unsigned short *) L"hello" };

	A workaround for this problem is to remove the cast to unsigned short *, because it is unnecessary.  The same problem affects unsigned char arrays initialized with non-wide string literals.  [trk2750]
	
	When -Qmem is specified, the Intel C/C++ Compiler might attempt an illegal interchange of a triangular loop, that is, a loop where the lower bound of the innermost loop is the outermost loop variable.  If the program contains a triangular loop, either do not use -Qmem or disable loop interchange by using the compiler option -mP2OPT_interchange=FALSE.  [trk2840]
	
	The Intel C/C++ Compiler issues an error if an identifier with a base type is redeclared using a different base type of the same size.  The Microsoft Visual C++ Compiler generates a warning in this situation.  [trk3317]

	The following code fragment fails to compile with the Intel C/C++ Compiler for this reason:

		int a;
		long a;
		float a;
	
	For a code fragment like the following:

		#define foo(a, b, c, d)  {			\
		    if (a ##d= b)					\
		        printf("c = %d\n", c);		\

		void main()
		{
		    foo(3, 29, 11, <);
		}

	the Intel C/C++ Compiler inserts a space between the expansion of the d parameter and the = operator.  The Microsoft Visual C++ Compiler will not insert a space.  [trk3338]
	
	When generating debug information for a function whose name is more than 500 characters long, the Intel C/C++ Compiler can abort with a segmentation violation.  [trk3681]
	
	Programs that redefine standard ANSI library functions, like strcat() or atoi(), might fail to link with -Qprof_gen.  This is because the runtime support linked in to support the program instrumented for profiling makes calls to some standard library routines that in turn may pull in other standard routines.  Note that a program can redefine standard ANSI library functions legally only if the corresponding standard header files are not included.  Furthermore, the routine must be defined as static.  The workaround is to rename the user-defined version of the standard library function.  [trk3795]

	The Intel C/C++ Compiler generates an error for a character array initialization containing a mixture of characters and strings such as the following:

		char a[5] = {'a',  "bcd"};

	The Microsoft Visual C++ Compiler supports this initialization.  [trk3906]
	
	Members of unnamed namespaces, classes, or unions can not be watched using a debugger.  [trk3968]
	
	When using profile-guided optimization (-Qprof_gen and -Qprof_use), the compiler may issue warnings such as

		WARNING: profile information will be ignored for
			C:\temp\c.c'func'

	This happens if you use the -O1 or -Os options for either the instrumentation compilation
	(-Qprof_gen) or the feedback compilation (-Qprof_use), but not for both.  The warning indicates that the compiler is unable to use the profile information gathered for the function named in the warning message.  This may negatively affect your program's speed, but will not affect its correctness.  The workaround for this problem is that if you use the -O1 or -Os options, use these options for both the instrumentation and feedback compilations.  [trk4092]

	In C compilations, the Intel C/C++ Compiler does not allow a non-lvalue expression of class/struct type (i.e. a call to a function returning a struct) to be used as an lvalue, although this is supported in C++ compilations.  The Microsoft Visual C++ Compiler supports this extension in both C and C++ compilations.  As a result, a reference to an array member of a struct returned by a function is not supported by the Intel C/C++ Compiler.  [trk4196]

	If both the -Yc (create precompiled header) and the -Yu (use precompiled header) options are specified on the same commandline, the Intel C/C++ Compiler honors the last of these options seen.  The Microsoft Visual C++ Compiler allows you to specify the -Yc and -Yu options on the same command line if both options have associated filenames and the filenames differ.  [trk4358]

	Passing more than eight floating point parameters to a function can cause the Intel C/C++ Compiler to abort with an INTERNAL COMPILER ERROR message.  A workaround for this problem is to place the floating point parameters in a struct and pass either a pointer to the struct or the struct itself as a parameter.  [trk4642]

	If you compile with optimizations disabled (-Od), the Intel C/C++ Compiler will generate incorrect code when an __int64 return value is assigned to a double variable.  The following program demonstrates this problem.

		__int64 foo(void)
		{
		    return 0xffffffff;
		}

		int main()
		{
		    __int64 i;
		    double x;

		    x = (double) foo();     /* workaround code:
		    printf("%15.2d\n", x);     i = foo();
		                               x = (double)i;
		                               printf("%15.2d\n", x);
		                             */
		    return 0;
		}

	When compiled with -Od, this program prints 00 instead of the correct answer -2097152.  The workaround for this problem is to assign the return value to an __int64 variable first, as shown in the example.  Or, compile with optimizations enabled (-O1 or -O2).  [trk4975]

	The Intel C/C++ Compiler uses an incorrect offset for members of unnamed unions when these members are referenced in inline assembly.  The following program prints 1 when compiled with the Intel C/C++ Compiler.  It should print 2.

		typedef struct {
		   int   beep;
		   union { int foo, bar; };
		} STRUCT;

		int main()
		{
		    STRUCT   str1;
		    int x;

		    str1.beep = 1;
		    str1.foo  = 2;

		    _asm {
		        lea   eax, str1
		        mov   ecx, [eax]STRUCT.foo
		        mov   x, ecx
		    }

		    printf("%d\n", x);
		    return 0;
		}

	The workaround for this problem is to use named unions when union members are referenced in inline assembly.  [trk5025]

	When the -Qvc5 option is used to specify interoperability with Microsoft Visual C++ Version 5.0, the Intel C/C++ Compiler fails to define the _MSC_EXTENSIONS macro.  This macro is defined by the Microsoft Visual C++ Compiler by default or when -Ze is specified.  The workaround is to define this macro in the icl.cfg configuration file.  [trk5035]

	When a jump instruction is specified with the SHORT qualifier in inline assembly, the Intel C/C++ Compiler emits a short jump (which has a range from -128 to 127 bytes of the next instruction's first byte) even if the target of the jump is not within range.  The Microsoft Visual C++ Compiler will emit a long jump in such a situation.  Use of a short jump in this case will likely lead to failure the executed program.  The workaround for this problem is to not use the SHORT qualifier unless you are sure that the target of the jump is within range of a short jump.  [trk5079]

Defects Affecting Only C++ Programs

	There are differences in overload resolution between the Intel C/C++ Compiler and the Microsoft Visual C++ Compiler.  If you have specific problems in this area we would appreciate hearing about them.

	If, in an expression of the form (e).m or (e)->m, m refers to a static data member or static member function, the expression (e) will not be evaluated, even if it has side effects, because its value is immaterial in referencing the member. According to the C++ language definition,  the expression should still be evaluated for its side effects.  [trk2546]

	The Intel C/C++ Compiler does not allow anonymous template-parameters.  An example of the use of anonymous template-parameters is given below.  [trk2555]

		template<class D, int>
		class C { public: D array[2]; };
		int main(void)
		{
		    C<int, 0> x;
		    return 0;
		}

	The Intel C/C++ Compiler does not yet support the ability to overload an operator with a non-member function taking a parameter with enum type, but no parameter with class type.  [trk2683]

	For an object allocated using operator new, the code generated by Intel C/C++ Compiler with the -GX (enable C++ exception handling) option will not call operator delete if an exception is thrown during construction of the object.  The code generated by the Microsoft Visual C++ compiler will call operator delete in this case.  [trk3261]

	The Intel C/C++ Compiler handles the throwing and catching of qualified objects, objects of types declared with const or volatile, differently from the Microsoft Visual C++ Compiler.  The Intel C/C++ Compiler follows the Draft ANSI C++ Working Paper in that throws of qualified objects are not caught by unqualified catch handlers, and vice versa.  The Microsoft Visual C++ Compiler allows a non-qualified catch handler to catch a qualified object, and vice versa.  [trk3466]

	Based pointers are not fully supported in C++ code.  Although they are accepted (i.e. do not result in an error), they are not taken into account in name mangling, for example.  [trk3535]

	If an asynchronous exception occurs and is handled by a C++ catch, it is possible to observe values of local variables that are not current in the catch.  A work around is to disable optimizations or to take the address of the local variable.  [trk3796] 

	The Intel C/C++ Compiler adheres to the Draft ANSI C++ Working Paper by not allowing thrown objects to be caught by handlers of protected base class types.  The Microsoft Visual C++ Compiler allows a catch handler for a protected base class to catch an exception thrown by a derived class.  [trk4046]

	The Intel C/C++ Compiler does not fully support conversions between pointer-to-member types involving virtual base classes.  Use of this feature may result in aborted compilations, and may also result in code which produces incorrect results at run-time.  [trk4157]

	The Intel C/C++ Compiler does not allow a definition of a static data member of a class unless the member was actually declared in the class.  Microsoft Visual C++ allows the definition of a static data member of a class if a base class has a static data member with the same name and type.

	If you encounter this problem, add an explicit declaration of the static member to the derived class.  [trk4389]

	When a class is a member of a namespace, and contains a friend declaration of function not already declared, the Intel C/C++ Compiler "injects" the function declaration into the namespace containing the class, even if the class definition is not lexically within the namespace definition.  Microsoft Visual C++ apparently "injects" the function declaration into the scope lexically containing the class definition.  As a result of this difference, friendship may be bestowed on a different function, and access errors may result.

	Since friend "injection" has recently been eliminated as a language feature by the C++ standardization committee, the interpretation of code which relies on the specific behavior of Microsoft Visual C++ Version 4.2 may change with future releases of Visual C++.  [trk4380]

	Microsoft Visual C++ allows token-pasting using a scheme such as the following:

		#define prefix() a
		#define paste_prefix(suffix) prefix()suffix
		paste_prefix(z)

	With Visual C++, this example would expand to a single identifier "az".  The Intel C/C++ Compiler supports token-pasting only when the ANSI token-pasting operator ## is used. [trk4405].

	If two different anonymous structs in a single scope both declare fields with the same name, the Intel C/C++ Compiler reports an error.  With Microsoft Visual C++, the duplicated name apparently refers to the first such declaration; later such declarations are inaccessible.

	If you encounter this problem, rename fields to avoid the clash(es). (Bit-fields used only for padding purposes need no name at all.)  [trk4417]

	In accordance with the C++ language specification, if a function declaration is encountered within a function definition, the function referenced is taken to be another member of the namespace of the containing function, whether or not the containing function definition is lexically within a namespace definition.  The Microsoft Visual C++ Compiler takes the referenced function to be a global function (not in any namespace).  Functions declared in global or namespace scope are interpreted the same way by both the Intel C/C++ Compiler and the Microsoft Visual C++ Compiler.  [trk4577]

Limitations and Tool Notes

The following are limitations of the Intel C/C++ Compiler and of using the Intel C/C++ Compiler with Microsoft development tools.

PDB Files and Debug Information
Because the Intel C/C++ Compiler does not use Microsoft's PDB format for debug information, object files with debug information are larger than those produced by the Microsoft Visual C++ Compiler.

Microsoft Macro Assembler Produces .SBR Files
Version 6.11 of the Microsoft Macro Assembler (MASM) produces a source-browser file (.SBR) when you assemble an assembly file (.ASM) using MASM.exe.  The Intel C/C++ Compiler for Win32 Systems calls MASM.exe to assemble files when you use the -Quse_asm option.  The compiler also calls MASM.exe to assemble .ASM files specified on the command-line.

To prevent the generation of .SBR files, you should make the following environment variable setting:

		ML=-Frnul

Assembly File Line Limit in Microsoft Macro Assembler Version 6.11
MASM 6.11 can handle a maximum of approximately 32760 lines.  If you attempt to assemble a .ASM file with more than 32760 lines, the assembler aborts with a fatal error.  Also, if you compile with the -Quse_asm option and the intermediate assembly file exceeds 32760 lines, the assembler also aborts.

Assembling .ASM Files Produced by the Intel C/C++ Compiler for Win32 Systems
The Intel C/C++ Compiler produces assembly files when the -S option is specified on the command-line.  Assembly files produced in this way can be assembled by specifying the files on the Intel C/C++ Compiler command-line.  For example, the following commands produce file.asm and then assemble that file to produce file.obj:

		icl -S file.c
		icl -c file.asm

Assembly files produced by the Intel C/C++ Compiler can be assembled using MASM 6.11.  Certain additional options are required when using MASM 6.11 to assemble files produced by the Intel C/C++ Compiler.  Use a command line similar to the following to call MASM:

		ml /c /coff /Cp /Zm file.asm

Limitations of Assembly Files (-S, -Quse_asm options)
Assembly files are produced by the -S option and are implicitly produced and assembled by the
-Quse_asm option.  Due to limitations in MASM and the assembly file format, it may not be possible to assemble .ASM files produced by the Intel C/C++ Compiler.  Specific features that are incompatible with assembly file usage are the following:

	Thread Local Storage using __declspec(thread) syntax
	Debug Information Generation using the -Zi, -Z7, or -Zd options.
	#pragma comment and the embedding of default library directives in the object file.  The following options are affected: -LD, -LDd, -MD, -MDd, -ML, -MLd, -MT, -MTd, -V
	COMDAT generation using the -Gf or -Gy options is not supported in assembly files.
	Building of multi-file C++ programs is not possible when assembly files are used, due to lack of support for COMDAT generation.

Coding Guidelines for Inline Assembly Effective Address Expressions
The Intel C/C++ Compiler supports a subset of the addressing syntax supported by Microsoft in Inline Assembly (__asm) effective address expressions.  Intel recommends use of the following addressing syntax as a guide:

		SIZE VAR [ BREG + IREG * SCALE {+|-} EXPR] DOT_EXPR

where

		SIZE		is a memory operand size qualifier (for example, DWORD PTR)
		VAR		is an optional variable reference
		BREG		is a 32-bit base register
		IREG		is a 32-bit index register
		SCALE		is 1, 2, 4, or 8
		EXPR		is an arithmetic expression
		DOT_EXPR 	is an optional structure member reference in the following form:

				. MEMBER_NAME

Technical Support and Customer Feedback

If you would like to provide feedback or if you encounter problems with installation or usage of the Intel C/C++ Compiler for Win32 Systems Version 2.4, we want to hear from you.

Please follow these guidelines when forming your bug report or product suggestion:

1.	Describe your difficulty or suggestion.
	For problem reports please be as specific as possible, so that we may reproduce this problem.  Please include the compiler options and a small test case if possible. 

2.	Describe your system configuration information.
	Be sure to include specific information that may be applicable to your setup: operating system, version numbers of the Intel C/C++ Compiler and the Microsoft Visual C++ Compiler, and anything else that is relevant to helping us address your concern.

Contact us with your suggestion or bug report at one of the following:

Electronic Mail: Our email support is available 24 hours a day. Please mail directly to the following address:

	developer_support@intel.com

A technical support engineer will return your email within one (1) Intel business day.

FAX: Our FAX support is available 24 hours a day. Please send complete information to the number listed below. A Technical Support engineer will respond within one (1) Intel business day.	

	FAX (916) 356-6100


Copyright(c) 1997-1998, Intel Corporation, All Rights Reserved.

* Other brands and names are the property of their respective owners.
