Making VS-compatible Windows Intel compiler as strict as Linux Intel compiler?

Making VS-compatible Windows Intel compiler as strict as Linux Intel compiler?

Hello,

  We develop for both Windows & Linux, but often developers work primarily on the Windows side, and when we later compile the same code on Linux the compiler chokes due to stricter syntax requirements (usually more need for 'typename' prefacing qualified types, and redeclaration of parent-class typedefs in templatized subclasses, etc.).

  I realize the Linux compiler is probably trying to maintain compatibilty with gcc, while the Windows compiler is trying to be compatible with Visual Studio.

  Is there some way to force our Windows code to be stricter, without using an entirely new, non-VS-compatible setup?  I tried /Qgcc-dialect:460, but this makes the Windows compiler choke on the Visual Studio /include files.

  Seems unlikely that there is a way to do this, but just thought I'd ask :).

thanks for any help   -- Daniel

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

Here's an idea, you could enable all diagnostics on Windows using the command line option /W3 and see if any of those desireable diagnostics match condiitons which are ordinarily detected as error/warning in the Linux compiler. Then you can adjust the severity level of those diagnostics upward using /Qdiag-error. More information here, http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011Update/compiler_c/copts/common_options/option_diag.htm

Melanie,

Here is an example of a program that compiles fine on Windows (icl) but not on Linux (icpc):

#include <iostream>

template<typename T>
struct BaseClass
{
typedef std::pair<T,T> TPair;
};

template<typename T, typename U>
struct Derived : public BaseClass<T>
{
typedef std::pair<TPair,U> TUPair;

Derived(TUPair x) : m_val(x) {}

TUPair m_val;
};

int main(int argc, char *argv[])
{
auto ipair = std::make_pair(1,1);
auto fipair = std::make_pair(ipair, 1.0f);
Derived<int,float> d(fipair);
return 0;
}

On Windows, it compiles without qualm.

Even if I use /W5 /Qdiag-error:port-linux, it only outputs this:

Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.3.198 Build 20130607
Copyright (C) 1985-2013 Intel Corporation. All rights reserved.

test.cpp
test.cpp(21): remark #383: value copied to temporary, reference to temporary used
auto ipair = std::make_pair(1,1);
^

test.cpp(21): remark #383: value copied to temporary, reference to temporary used
auto ipair = std::make_pair(1,1);
^

test.cpp(21): remark #981: operands are evaluated in unspecified order
auto ipair = std::make_pair(1,1);
^

test.cpp(22): remark #383: value copied to temporary, reference to temporary used
auto fipair = std::make_pair(ipair, 1.0f);

On Linux, though, just using 'icpc test.cpp -o test' yields:

test.cpp(12): error: identifier "TPair" is undefined
typedef std::pair<TPair,U> TUPair;
^

test.cpp(21): error #303: explicit type is missing ("int" assumed)
auto ipair = std::make_pair(1,1);
^

test.cpp(21): error: no suitable conversion function from "std::pair<int, int>" to "int" exists
auto ipair = std::make_pair(1,1);
^

test.cpp(22): error #303: explicit type is missing ("int" assumed)
auto fipair = std::make_pair(ipair, 1.0f);
^

test.cpp(22): error: no suitable conversion function from "std::pair<int, float>" to "int" exists
auto fipair = std::make_pair(ipair, 1.0f);
^

test.cpp(23): error: no instance of constructor "Derived<T, U>::Derived [with T=int, U=float]" matches the argument list

argument types are: (int)
Derived<int,float> d(fipair);

Any more thoughts?

thanks again,

Daniel

ksh-3.2$ icl -c -Qoption,c,--dep_name fu.cpp
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0 Beta Build x
Built Oct 18 2013 12:48:39 ...
Copyright (C) 1985-2013 Intel Corporation. All rights reserved.

fu.cpp
fu.cpp(12): error: identifier "TPair" is undefined
typedef std::pair<TPair, U> TUPair;
^

BTW, you could set this option for the compiler installation using the configuration file.  It's about "dependent name lookup" method.

Very nice, I did not know about that flag.

Is there a way to get it to play nicely with the MSVC standard libraries? :)

E.g. if I insert

std::vector<int> x(3);

after the instantiation of 'Derived' (in 'main', after fixing the dependent-name problem and #including <vector>), I get this from icl /W3 /Qoption,cpp,--dep_name:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\xmemory0(80): error: no instance of overloaded function "
std::_Destroy_range" matches the argument list
argument types are: (int *, int *, std::_Wrap_alloc<std::allocator<int>>, std::_Scalar_ptr_iterator_tag)
_Destroy_range(_First, _Last, _Al, _Ptr_cat(_First, _Last));
^
detected during:
instantiation of "void std::_Destroy_range(_Alloc::pointer, _Alloc::pointer, _Alloc &) [with _Alloc=std::_Wr
ap_alloc<std::allocator<int>>]" at line 1480 of "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\vector"
instantiation of "void std::vector<_Ty, _Alloc>::_Destroy(std::vector<_Ty, _Alloc>::pointer, std::vector<_Ty
, _Alloc>::pointer) [with _Ty=int, _Alloc=std::allocator<int>]" at line 1415 of "C:\Program Files (x86)\Microsoft Visual
Studio 11.0\VC\INCLUDE\vector"
instantiation of "void std::vector<_Ty, _Alloc>::clear() [with _Ty=int, _Alloc=std::allocator<int>]" at line
1383 of "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\vector"
instantiation of "std::vector<_Ty, _Alloc>::iterator std::vector<_Ty, _Alloc>::erase(std::vector<_Ty, _Alloc
>::const_iterator, std::vector<_Ty, _Alloc>::const_iterator) [with _Ty=int, _Alloc=std::allocator<int>]" at line 1061 of
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\vector"
instantiation of "void std::vector<_Ty, _Alloc>::resize(std::vector<_Ty, _Alloc>::size_type) [with _Ty=int,
_Alloc=std::allocator<int>]" at line 696 of "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\vector"
instantiation of "std::vector<_Ty, _Alloc>::vector(std::vector<_Ty, _Alloc>::size_type) [with _Ty=int, _Allo
c=std::allocator<int>]" at line 30 of "test2.cpp"

I realize I'm perhaps asking for inconsistent behavior -- just thought I would try... .

Searching around for other Qoption parameters turned up -Qoption,cpp,--no_implicit_typename, which seemed like it might solve the other main incompatibility we see, but it seems to cause other problems with code that icpc _does_ accept.

Is there documentation for the options to -Qoption,cpp available?

thanks again,

Daniel

I don't see the error message that you report after changing the program to add vector. I'm using a developmenet compiler so that could account for the difference, or it might be something else. Also the Qoption's aren't officially documented. We don't support a mode like you asked for in your first post.

Melanie,

  Here is a complete program.  If I compile this with 'icl -Qoption,cpp,--dep_name', with Visual Studio 2012 installed, I get the previously posted error.

#include <vector>

int main(int argc, char *argv[])
{
std::vector<int> x(3);
return 0;
}

Also, I take it back about --no_implicit_typename -- the errors I was getting were due to a problem in my program.  It _does_ work OK with the Visual Studio headers.  So this at least solves part of our problem.

thanks for your help,

Daniel

Please try to use these Intel C++ compiler command line options:

/W5
/Wport
/Qeffc++

Hi Sergey,  

  Thanks for looking at this thread.

  I mentioned the result of using /W5 above: just a bunch of trivial, unhelpful warnings.  Using /Qport adds nothing.  Using /Qeffc++ only adds a minor warning that "non-explicit constructor with single argument may cause implicit type conversion".

  I posted the source program above, so you can try other flags yourself if you like.

thanks again,

Daniel

Leave a Comment

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