Compatibility of Intel, Microsoft, Borland and MinGW C++ compilers

Compatibility of Intel, Microsoft, Borland and MinGW C++ compilers

I detected a problem with MinGW ( GCC-like ) C++ compiler. It is a well known fact that Intel C++ compiler
is compatible with Microsoft C++ compiler on Windows platforms, and compatible with GCC C++ compiler
on Linux platforms.

Since I don't have a Linux platform I wonder if somebody could verify the following Test Case with
32-bit and 64-bit Intel C++ compilers for Linux. Some modifications related to '_WIN...' macros and
the '__w64' keyword are needed.

	...

	// Test Case - Verification of __w64 keyword

	// 'V64C' stands for 'Verify 64-bit Compatibility'
	...

	#if ( defined ( _WIN32_MSC ) || defined ( _WIN32_ICC ) )

	#define _RTV64C			__w64

	#endif

	#if ( defined ( _WIN32_MGW ) )

	#define _RTV64C

	#endif

	...
	#define _WIN64

//	#undef _WIN64
	typedef int Int_32;
	#ifdef _WIN64

	typedef __int64 Int_Native;

	#else

	typedef int _RTV64C Int_Native;

	#endif
	Int_32 iInt_32 = 0xffeeddcc;			        // MinGW 32-bit:

//	Int_Native iInt_Native = 0xffffeeeeddddcccc;	// Error: integer constant is too large for "long" type

//	Int_Native iInt_Native = 0x0fffeeeeddddcccc;	// Error: integer constant is too large for "long" type

//	Int_Native iInt_Native = 0x00ffeeeeddddcccc;	// Error: integer constant is too large for "long" type

//	Int_Native iInt_Native = 0x000feeeeddddcccc;	// Error: integer constant is too large for "long" type

//	Int_Native iInt_Native = 0x0000eeeeddddcccc;	// Error: integer constant is too large for "long" type

//	Int_Native iInt_Native = 0x00000eeeddddcccc;	// Error: integer constant is too large for "long" type

//	Int_Native iInt_Native = 0x000000eeddddcccc;	// Error: integer constant is too large for "long" type

//	Int_Native iInt_Native = 0x0000000eddddcccc;	// Error: integer constant is too large for "long" type

	Int_Native iInt_Native = 0x00000000ddddcccc;	// Compiled

	iInt_32 = iInt_Native;
	#undef _WIN64

	...

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

What exactly are you trying to do with MinGW? It is a very poor compiler by the way.

Regards,
Igor Levicki

I suppose you could argue that /Qgcc-dialect for ICL 13.0 should enable those standard compliance warnings which you get with gcc. Your comments might make more sense to me if you had a compilable fragment with code showing the version of the long constants which gcc accepts (an example which could be posted as a feature request on premier.intel.com, if in fact the dialect option doesn't help).
This option, among others, was not publicized as something to test during the period for accepting reports on the beta test.
I'm not even certain from your comments whether your argument may be that there should be an option to have the ICL 64-bit Windows integer data types named the same as in linux. In that case, either an L or LL suffix (or UL/ULL) should make 64-bit constants work.
Mingw compiler has improved significantly, but I spent several hours attempting myself to build an up to date version and gave up. I would have doubts whether they would succeed in catching up on the project to make it link-compatible with Visual Studio. I think cross platform source compatibility may be a stronger argument for this gcc-dialect option.

Quoting TimP (Intel)...In that case, either an L or LL suffix (or UL/ULL) should make 64-bit constants work.

[SergeyK] Thanks. I'll try it.

Mingw compiler has improved significantly, but I spent several hours attempting myself to build an up to date version and gave up.

[SergeyK] I agree that there are some "integration problems" and about 2 years agoit tooka couple of weeks
to complete theintegration.

I would have doubts whether they would succeed in catching up on the project to make it link-compatible with Visual Studio...

[SergeyK] Any libraries created with MinGW are compatible ( asignature '!' is at the beginning )
with libraries created withMicrosoft C++ compiler.
Here is a link to a screenshot that demonstrates how MinGW compiles sources from Visual Studio 2005:

http://software.intel.com/en-us/forums/showthread.php?t=97240&o=a&s=lr

Take a look at a Post #4.

Best regards,
Sergey

Quoting Igor LevickiWhat exactly are you trying to do with MinGW? It is a very poor compiler by the way.

Hi Igor, Please take a look at a thread:

http://software.intel.com/en-us/forums/showthread.php?t=106134&o=a&s=lr
( Post #3 )

and I'll also provide a small example regarding detection of some issues with MinGW, Inteland Microsoft C++ compilers.

Best regards,
Sergey

Here is a Test-Case:

...

template < class T, RTint iDataType > class TDataSet

{

public:

	...

	T *m_ptData1D;

	...

};
template < class T, RTint iDataType > class TMatrixSet : public TDataSet< T, iDataType >

{

	...

	inline RTbool TransposeClassic( RTvoid )

	{

		...

		if( TDataSet< T, iDataType >::m_ptData1D == RTnull )   // V1 - MSC - OK  MinGW - OK

	//	if( m_ptData1D == RTnull )                             // V2 - MSC - OK  MinGW - Error

			...

	};

	...

};

...

>> Compilation Error <<

------ Build started: Project: MgwTestApp, Configuration: Debug Win32 ------
Performing Makefile project actions
*** ScaLib Message: Compiling with MinGW v3.4.2 ***
*** ScaLib Message: Configuration - Desktop - _WIN32_MGW - DEBUG ***
In file included from ../../Include/CommonSet.h:22,
from Stdphf.h:110,
from MgwTestApp.cpp:11:
../../Include/MatrixSet.h: In member function `RTbool TMatrixSet::TransposeClassic()':
../../Include/MatrixSet.h:76: error: `m_ptData1D' undeclared (first use this function)
../../Include/MatrixSet.h:76: error: (Each undeclared identifier is reported only once for each function it appears in.)
MgwTestApp - 2 error(s), 0 warning(s)

>> Notes <<

MinGW C++ compiler is a very-strict C++ compiler compared to Microsoft and Borland C++ compilers.

I would rate Intel C++ compiler as a double-strict C++ compiler compared to Microsoft, MinGW and
Borland C++ compilers when a 'Warning Level' option '/W5' is used.

Quoting Sergey KostrovQuoting TimP (Intel)...In that case, either an L or LL suffix (or UL/ULL) should make 64-bit constants work.

[SergeyK] Thanks. I'll try it.
...

It works and here areresults ( lines 4, 5, 6, 7 ):

  ...

  Int_Native iInt_Native1 = 0x00000000ddddcccc;		// Compiled

  UInt_Native uiUInt_Native1 = 0x00000000ddddcccc;	// Compiled

  Int_Native iInt_Native2 = 18446725308424768716LL;	// Warning: this decimal constant is unsigned only in ISO C90

  UInt_Native uiUInt_Native2 = 18446725308424768716LL;// Warning: this decimal constant is unsigned only in ISO C90

  Int_Native iInt_Native3 = 18446725308424768716ULL;	// Warning: this decimal constant is unsigned only in ISO C90

  UInt_Native uiUInt_Native3 = 18446725308424768716ULL;	// Warning: this decimal constant is unsigned only in ISO C90

//Int_Native iInt_Native4 = 0xffffeeeeddddcccc;		// Error: integer constant is too large for "long" type

//UInt_Native uiUInt_Native4 = 0xffffeeeeddddcccc;	// Error: integer constant is too large for "long" type

  ...

Instead of0xffffeeeeddddccccI used18446725308424768716.

Leave a Comment

Please sign in to add a comment. Not a member? Join today