BIG Problems with Inel C++ and Visual Studio 2017

[hills__adrian]

Some years ago (actually, quite a few), I used to rely on the Intel C/C++ Compiler to check my software for subtle/potential errors: it was brilliant.

Then, a few day ago, Intel granted me an "Educator" licence for their latest offerings (Parallel Studio XE and System Studio).

Great, I thought ...

.. but, after several failures during attempts at installation, I finally got the thing(s) installed (or, so  I thought).  Go into Visual Studio, open one of my current solutions, and switch to "Use Intel Compiler!"

Fart! Cannot compile the MFC headers (brain-dead compiler, doesn't recognize "friend class XXX;" as a declaration of a class).  For a few issues, I can fix this (putting in explicit "class XXX;" before I #include the "afx..." headers). Then all sorts of other (similar) errors.  THIS COMPILER IS NOT COMPATIBLE WITH MSVC.

In a smaller project, I could get round the system header problems, only to be confronted with a "catastrophic error" when creating a pre-compiled header.

So, I switched back to using the Visual Studio compiler, and now my projects won't build (cannot find libmmd.lib).

Enough! Get rid of the whole thing! But, do you know what? I cannot now properly uninstall Intel Parallel Studio: Keeps telling me Visual Studio is running ... which it isn't!

The irony is that I wanted the Intel Compiler to teach students how to write ROBUST software! What I get, instead, is a package that sells (in the real world) for around $3,000 which is a brilliant example of what BAD software is!

Get your act together, guys!

[Viet_H_Intel]

Can you please let us know which version of Intel compiler and version of VS2017 that you are using?

Thanks,

Viet 

[hills__adrian]

Hi,

Visual Studio is Version 15.7.1 (Community edition) and Intel C++ is 18.1 Update 2.  The problem with the MFC headers, though, will date back to VS2015, as MFC hasn't been changed since then.  As for the other Windows headers, I don't know when Microsoft last updated these.

I would have expected ICC to be able to build an MFC application, though.

Also, the 'catastrophic' problem with the precompiled headers (not being able to get memory) seems to date back to Intel C++ version 16.0, from what I can glean from the various web forums. I tried one of the suggested fixes (adding /Qpch=0x20000000, or some such) but that made no difference.

As for the issue of not finding "libmmd.lib" after switching back to "Use Visual C" - this strikes me as a bit naughty: an Intel trick to incorporate proprietary code?

[jase439]

I just created a default MFC application and compiled it without error using VS2017 15.7.2 and ICC 18 Update 2. Perhaps there is a problem with your VS installation or your include paths?

[hills__adrian]

OK, maybe there's something weird in my overall header file (equivalent to the StdAfx.h file used in VS examples); I use the same file for all projects in my solution - I call it _Environ.h and have an 'empty' _Environ.cpp in each project that creates the PCH for that project.

It's actually quite a big header, with a number of compiler- and platform-specific conditional blocks, but the essential parts that are included when using Visual C++ (i.e. when _MSC_VER is defined) are as below; maybe you could try putting this in your StdAfx.h and see if that generates the errors I see? (You should be able to copy/paste this as is.) Although many of the included headers will not be required by your MFC app, they should still be processed by the compiler ...

Thanks for your reply and efforts!

// ================================================================================================================

// First, set up some 'standard' (actually Microsoft-specific) tokens to optimise/standardise the compiler options:

#ifndef NDEBUG

#define NDEBUG 1 // Do not include DEBUG parts of SYSTEM headers

#endif

#ifdef _DEBUG

#undef _DEBUG

#endif

#ifndef STRICT

#define STRICT 1 // Enforces STRICT compiler type-checking, etc.

#endif

#include <SDKDDKVer.h> // Header for versioning the windows SDK/DDK packs - used by C++ and resource compilers

// ------------------------------------------------------------------------------------------------------------

#if defined (__INTEL_COMPILER) // Check to see if we're using the Intel C++ compiler (within Visual Studio)...

#define INTELC __INTEL_COMPILER

#elif defined (__ICC)

#define INTELC __ICC

#elif defined (__ICL)

#define INTELC __ICL

#elif defined (INTELC)

#undef INTELC

#endif

#ifndef VC_EXTRALEAN

#define VC_EXTRALEAN // Excludes rarely-used stuff from headers

#endif

#ifndef _ATL_CSTRING_EXPLICIT_CONSTRUCTORS

#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // Ban implict CString convert

#endif

#ifndef _AFX_ALL_WARNINGS

#define _AFX_ALL_WARNINGS

#endif

// ------------------------------------------------------------------------------------------------------------

// Turn off warnings generated by the "standard" and "MFC" header files. *** Note: using "#pragma(push, 2) ...

// #pragma(pop)" to embrace these header files doesn't work! *** [For some reason (possibly something weird in

// one of the headers), warnings such as 'unused parameters' and 'signed/unsigned' are not re-enabled.] ...

#pragma warning(disable:4191) // unsafe conversion to AFX_PMSG(W) (MMAP)

#pragma warning(disable:4263) // member function does not override . ...

#pragma warning(disable:4264) // no override avialable for virtual mem/f

#pragma warning(disable:4266) // no override available for member func'n

#pragma warning(disable:4302) // truncation from 'HIMAGELIST' to 'WCHAR'

#pragma warning(disable:4365) // conversion has signed/unsigned mismatch

#pragma warning(disable:4619) // pragma there's no warning number 'xxx'!

#pragma warning(disable:4625) // copy constructor could not be generated

#pragma warning(disable:4626) // assignment operator .. .. .. ..

#pragma warning(disable:4640) // construction of local static not thread

#pragma warning(disable:4668) // 'xxxx' not a defined preprocessor macro

#pragma warning(disable:4710) // The function 'fn-name' was not inlined!

#pragma warning(disable:4711) // Function selected for in-line expansion

#pragma warning(disable:4820) // 'n' bytes of padding added in structure

#pragma warning(disable:4917) // some MSVC compiler nonsense about GUIDs

#pragma warning(disable:4986) // exception specification: does not match

#pragma warning(disable:4987) // nonstandard extension 'throw(...)' used

#if (_MSC_VER >= 1900) // Visual Studio 2015/17 extra warnings...

#pragma warning(disable:4471) // a forward declaration of un-scoped enum

#pragma warning(disable:4768) // _declspec before linkage attrib ignored

#pragma warning(disable:4774) // 'sprintf_s()' format specifier warning!

#pragma warning(disable:5026) // move constructor was implicitly defined

#pragma warning(disable:5027) // move assign't op was implicitly defined

#pragma warning(disable:5038) // Data member will be initialized after!!

#pragma warning(disable:5039) // Pointer or reference to throwing func!!

#endif

#if (_MSC_VER >= 1914) // New (mad) warnings on release 15.7.0...

#pragma warning(disable:4571) // Informational: catch() sematics changed

#endif

#include <afxwin.h> // Minimal set of afx... (MFC) headers for the things we want to do ... (?)

#include <afxext.h>

#include <afxole.h>

#include <afxdll_.h> // Definitions of APIs required for creating extension DLLs

#include <afxwinappex.h> // Required for the base application class: MFC's CWinAppEx

#include <afxmdiframewndex.h> // Base frame windows "CMDIFrameWndEx" and "CMDIChildWndEx"

#include <afxcontrolbars.h> // This provides MFC's 'new-look' control bars and toolbars

#include <afxdialogex.h> // The extended dialogue-box base class - MFC's "CDialogEx"

#include <afxinet.h> // Definitions for the "CInternetSession" MFC class, and related procedures

#include <afxtempl.h> // This provides the definitions for MFC's "CArray" (growable) base classes

#include <locale.h> // Declarations/definitions of localisation routines, notably _wsetlocale()

#include <float.h> // Floating-point support: definitions of _isnan(), _finite() and "DBL_MAX"

#include <SetupApi.h> // Setup and Device Installer Services: to capture the physical screen info

#include <Mmsystem.h> // Mulitmedia APIs - play sounds in various alert message boxes

#include <WinSpool.h> // Printing APIs - we require for "Print QR Codes" stuffs

#include <Wia.h> // "Windows Image Acquisition" - scanner and camera interfaces

#include <intrin.h>

#include <nmmintrin.h>

#include <msi.h> // We need these two headers for the DLL interface to the installer ...

#include <msiquery.h> // ... this is called by MSI when running the ".msi" installer package.

#include <WinIoCtl.h> // For various disk-information-retrieving functions and strutures

#include <Dbt.h> // For definitions of DBT_DEVICEARRIVAL, DBT_DEVICEREMOVEPENDING etc...

#include <new> // So we can use the "nothrow" version of "operator new[] ()"!

#include <sstream> // So we can use wstringstream and ">>" instead of _swscanf()!

using namespace std;

#pragma warning(default:4191)

#pragma warning(default:4263)

#pragma warning(default:4264)

#pragma warning(default:4266)

#pragma warning(default:4302)

#pragma warning(default:4365)

#pragma warning(default:4619)

#pragma warning(default:4625)

#pragma warning(default:4626)

#pragma warning(default:4640)

#pragma warning(default:4668)

// #pragma warning(default:4710) // Functions selected for inline expansion and those declared as INLINE but

// #pragma warning(default:4711) // not inlined: there are numerous references to these in standard headers!

#pragma warning(default:4820)

#pragma warning(default:4917)

#pragma warning(default:4986)

#pragma warning(default:4987)

#if (_MSC_VER >= 1900) // Visual Studio 2015/17 extra warnings...

#pragma warning(default:4471) // a forward dedclaration of unscoped enum

#pragma warning(default:4768) // _declspec before linkage attrib ignored

#pragma warning(default:4774) // 'sprintf_s()' format specifier warning!

#pragma warning(default:5026) // move constructor was implicitly defined

#pragma warning(default:5027) // move assign't op was implicitly defined

#pragma warning(default:5038) // Data member will be initialized after!!

#pragma warning(default:5039) // Pointer or reference to throwing func!!

#pragma warning(disable:4239) // Non-standard extension used: conversion from <class> to &<class>

#endif

#if (_MSC_VER >= 1914) // New (mad) warnings on release 15.7.0...

#pragma warning(default:4571) // Informational: catch() sematics changed

#pragma warning(disable:5045) // Complier will insert Spectre mitigation

#endif

// The following macros and inline functions allow us to use Microsoft 'safe' string functions where this

// is appropriate (in the MSVC builds) but we continue using the standard C functions with other platform

// compilers ...

#define WCSCPY(dst, src) wcsncpy_s(dst, _countof(dst), src, _TRUNCATE)

static inline FILE *_WFOPEN(const wchar_t *name, const wchar_t *mode) {

FILE *fp; return (_wfopen_s(&fp, name, mode) == 0) ? fp : nullptr;

}

#ifdef PTM_WARNING_DISABLE // The newer versions of MFC do not disable the warning that the function

#undef PTM_WARNING_DISABLE // given to handle a standard Windows message (e.g. ON_WM_DRAWITEM), in a

#endif // MESSAGE_MAP does not comply with the AFX_PMSG definition; so we add it

#ifdef PTM_WARNING_RESTORE // here, replacing disabling the "C4867" warning - which we can now avoid

#undef PTM_WARNING_RESTORE // by using the ANSI-conformant syntax for functions in these maps (using

#endif // the "&MyClass::Member" specification, not simply "Member") ...

#define PTM_WARNING_DISABLE __pragma(warning(disable:4191))

#define PTM_WARNING_RESTORE __pragma(warning(default:4191))

[hills__adrian]

Jason,

I though I should take up the mantle again - so I've re-installed ICC and found that I, too, can build a default MFC app using ICC!

So, I need to check which of my project/solution settings is upsetting the apple cart.

But I've now noticed other errors: Major: Trying to open a second solution (i.e. have my default MFC app open, then double-clicking on my 'problematic' .sln file) causes VS to hang! This didn't happen before I installed ICC.

I'll try to get round this an then, one-by-one, copy my settings across from 'problem' to 'default' - to see at which point the system fails.

Once again, thanks for your reply.

Adrian

[hills__adrian]

Aha!

Nailed it!

There's a new feature in MSVC since 15.7.0 called "Conformance Mode" Go to Project -> Properties -> C/C++ -> Language and select "Yes" for Conformance Mode (/permissive-). This will cause the ICC compiler errors in the MFC and Windows headers.

Around 15.7.0 (or maybe 15.7.1), if I didn't enable this new switch, MSVC would give me warnings/errors; this seems to have been fixed in 15.7.2, so I can live with that.

Also, the "cannot find libmmd.lib" error had maybe gone now (reinstallation of ICC may have fixed that) - but are build with MSVC now using this Intel replacement code? Not sure.

BUT - The remaining MAJOR ERROR is this problem with creating a precompiled header: "unable to obtain mapped memory" (see pch_diag.txt, attached).

Regards,

Adrian

.

[jase439]

That makes some sense.

In 15.7, MS made a decision to rollout with conformance mode enabled by default for all new projects. This also has the side effect of setting __cplusplus to the correct version (something MS hasn't been able to do in nearly twenty years):

https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/

While I was pleased to read about this change, I was skeptical that enabling it by default was the right play. It seems that MS came to that realization and set the default back to off in 15.7.2. There was an earlier thread a few weeks back in this forum about the fact that __cplusplus is not correctly defined and I believe that was directly attributed to MSVC being non-conformant (and consequently, ICC has to take that into account).

ICC for Windows relies heavily on the host compiler's libraries, headers, and environment and likely takes into account any conformance deficiencies/deviations that the host compiler introduces. By MS "fixing" these issues, it will likely require a change in kind to ICC. The rapid iterative (and volatile) rollout of changes (and many of them MAJOR) to VS2017, while great for consumers, has got to be a royal PITA for third-party developers who rely on age-old behavior which now can change like the blowing of the wind - esp. ICC, whose release cycle is substantially longer than Microsoft's new cadence.

I love VS2017, but I've had to hold my breath with every minor point release from MS wondering what will halt and catch fire next.

Case in point, my team is on ICC 17 Update 5 and VS2017 15.3, but recently tried to patch VS only to learn that ICC 17's terminal stop is 15.3.x (barring another update which Intel has yet to confirm). So we either stand pat at VS 15.3.x or we have to rollout ICC 18 and then plug all the holes that spring from that change. Can't win!

[hills__adrian]

Thanks for the explanation! I can understand that keeping ICC in synch with MSVC present difficulties, especially with the frequent recent updates to VS2017; they have been almost daily for a few weeks but there seems to been a slight settling down to around weekly since 15.7.2!

It would be nice to be able to switch /permissive- on or off with #pragma lines in header code! Alternatively (something I haven't been able to do but may be possible) be able to switch between the MSVC and ICC compilers in different project configurations would help. At the moment, switching to use ICC applies to all configurations/platforms in the selected project. [EDIT: I figured this one out! Select ICC from the "Platform Toolset" in the relevant configuration's properties sheet.]

But the big remaining issue is the inability to use precompiled headers! I have a solution with 16 projects (static LIBs, DLLs and EXEs) and a total of around 140 C++ source files: having the compiler sift through all the MFC/system headers 140 times rather than 16 times makes the overall build process very much slower, obviously!

I'll look around this and other forums for possible remedies ... somewhere, Intel reported (for ICC 16.0) that this was an extremely rare problem; however, I get it every time on every project, and even in other solutions (including the default MFC app I built up, as described earlier).

FYI I am using a 64-bit Windows 7 system; is ICC really a 32-bit WOW64 program, or does it install in /Program Files (x86)/ by mistake?

Regards

[jase439]

There is currently a feature request logged to enable/disable permissive mode via #pragma. No idea if/when it will be implemented. Would be a nice feature to have, however.

ICC is 32-bit because Visual Studio is 32-bits.