Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7944 Discussions

Intel Compiler Classic 2021.1.1 and 2021.1.2 patch not recogizing c++17 standard libraries

RJM
Beginner
2,562 Views

I am using OneAPI Base and HPC toolkits on Windows 10 64-bit, integrated with VS 2019 16.7.7 Enterprise Edition.  My compiler is set to Intel 19.2, and compiling with the -E option with banner suppression turned off confirms that icl.exe is in fact being invoked.  The compiler options printed to the output window confirms that /Qstd=c++17 is present.  Below is the command that invokes the compiler with all options.  I have also attached the *.i files converted to *.txt. In my case, I see the failure happening in both my code and in TBB concurrent data structure code.  I have replicated this behavior in Visual Studio 16.5.5, 16.7.12, and 16.8.6.  Any ideas about why the C++17 libraries are not being recognized?  I'm out of ideas at this point.

1>icl /Qm64 /Zi /W3 /O2 /Oi /Qipo -D __INTEL_COMPILER=202110 -D __TBB_CPP17_DEDUCTION_GUIDES_PRESENT -D _CRT_SECURE_NO_WARNINGS -D BOOST_USE_WINDOWS_H /P /EHsc /MD /GS /Gy /QxCORE-AVX2 /permissive- /Zc:wchar_t /Zc:forScope /Zc:inline /Qopenmp /Qstd=c++17 /Fox64\Release\ /Fdx64\Release\vc142.pdb /TP /FC -E Driver.cpp mapped_file.cpp

0 Kudos
14 Replies
RJM
Beginner
2,520 Views

No ideas from anyone as to why Intel Compiler Classic is not recognizing the C++17 language standard?  I just tried in Visual Studio 2019 16.9 Professional with the same results.  I have also used Intel Compiler 2021 with the same results.  Surely this is a configuration problem, but I have no idea what the error could possibly be.  I would appreciate some feedback.

0 Kudos
RJM
Beginner
2,504 Views

I have identified as far as is visible to me on the user end what is causing the problem. The _MSVC_LANG macro expands to 201402L for Intel Compiler 2021 and for 19.2 regardless of the language standard set. I suspect a similar issue when DPC++ is used, but have not checked. The MSVC compiler correctly expands the macro to 201703L. I do not see a way to fix that on my end.

0 Kudos
PrasanthD_intel
Moderator
2,496 Views

Hi Robert,

Intel compiler does support c++17 standard there might be some inconsistencies with the configuration in your environment.

Could you once double-check that you are changing the configuration that you are running? Like in the settings you may set for Release and x64 but may have tried to run with the Debug configuration and x86.

Also, once try manually setting the _HAS_CXX17 to see if it helps

For eg: 

 

#ifdef _HAS_CXX17
#undef _HAS_CXX17
#endif
#define _HAS_CXX17 1

 

 

Could you please provide us a minimal reproducer/sample code with the visual studio config file(.vcxproj) so that we can get more insights into your problem?

 

Regards

Prasanth

0 Kudos
RJM
Beginner
2,477 Views

As far as I can see, everything is right.  Here is a minimal code that reproduces the problem.  I confirmed that it does in fact build successfully, but Intellisense is reporting that filesystem is not in namespace std.  It uses the Intel 19.2 compiler with the language standard set to /Qstd=c++17.  When I check the value of _MSVC_LANG, it expands to 201402L when the Intel compiler is used (when 19.2 is used and Use Visual C++ compiler is set to No, or when 2021 is used and Use Visual C++ Compiler is set to yes with the appropriate language standard set for MSVC and/or Intel) even if the standard is set to /Qstd=c++17.  When the Microsoft compiler is used, it expands correctly to 201703L when /std:c++17 is used.  I have not found a configuration setting or combination of settings that causes the _MSVC_LANG to expand correctly to 201703L when Intel compilers are used with MSVC backend.  I have attached the vcxproj file as a zip file.

#include <numeric>
#include <filesystem>
#include <iostream>

#ifdef _HAS_CXX17
#undef _HAS_CXX17
#endif
#define _HAS_CXX17 1

int main()
{
int i = 14;
int j = 17;
std::cout << "Max is: " << std::max(i, j);
std::filesystem::path p;

return 0;
}

0 Kudos
RJM
Beginner
2,449 Views

After more experimentation, I found that many of these errors that I was seeing were IntelliSense errors, and I found something that works.
(1) Upgrade VS to 16.9
(2) Install oneAPI Base Toolkit and oneAPI HPC Toolkit
(3) Select Intel Compiler 19.2 as the project compiler in Visual Studio (this will invoke icl.exe)
(4) Select *BOTH* /Qstd=c++17 *AND* /std:c++17.

This appears to be an undocumented difference between Intel Compiler Classic 19.2 and Intel Compiler Classic 19.1. In 19.1, both standards were not required to avoid IntelliSense errors or other misleading errors.  In 19.1, I just set /Qstd=c++17 and that would handle everything.  In 19.2, it seems to be the case that both /Qstd=c++17 has to be set and /std:c++17 has to be set. 

Otherwise, the default language standard for MSVC is assumed, which is C++14, even though Intel Compiler Classic is setting C++17.  The resulting behavior is as follows: since MSVC assumes C++14 by default, _MSVC_LANG is set to 201402, which in turn defines __TBB_LANG as 201402, resulting in IntelliSense errors on trailing return types even though the build is successful.  On the other hand, if both standards are set, the macros expand correctly to 201703.  However, in earlier versions of VS, such as 16.5.5, IntelliSense errors still appear on trailing return types for oneTBB's concurrent data structures.  This error does not persist in VS 16.9, so long as both standards are set to C++17. 

Perhaps this difference in the behaviors of Intel Compiler Classic 19.1 and 19.2 (the version number that appears in the Visual Studio integration) and the requirements for project properties as they relate to oneAPI's Intel Compiler Classic could be better documented.  I found nothing in the compiler manual that would have led me to expect this sort of difference in Intel Compiler Classic versions.  One thing to note is that in doing the steps I outlined above, I see a warning that /Qstd=c++17 and /std:c++17 conflict with each other, and that the developer should consider using /Qstd=c++17.  This leads me to believe that this behavior with oneAPI's Intel Compiler Classic is not intentional.  If it were, then the warning is unnecessary and probably would have been removed.

0 Kudos
PrasanthD_intel
Moderator
2,339 Views

Hi Robert,

 

Glad you have the solution.

Thanks for your suggestion.

The same was not the case when we have tested. For us setting up /Qstd was enough and we wanted to know what might be causing this issue for you. 

We have tested with your vsproj file and still with your configuration properties setting we are not facing your issue. There might be some integration issues.

Could you please provide us the build output after keeping flag -# in your command line.

 

Regards

Prasanth

0 Kudos
PrasanthD_intel
Moderator
2,269 Views

Hi Robert,


We haven't heard back from you.

Could you please provide us the build output as mentioned in the previous post? That would help us in finding the cause of the issue.


Regards

Prasanth


0 Kudos
RJM
Beginner
2,248 Views

My apologies.  I never received a notification that you had posted until today.  I will get that for you this evening. 

 

Regards,

RJM

0 Kudos
RJM
Beginner
2,234 Views

I realized as I got to work on this that I changed the underlying project as I was working on something else.  Here is the build output for a small variation on the code snippet above.  It builds with no problems with MSVC using the C++17 standard. Using Intel Compiler Classic 19.2 and including <tbb/tbb.h>, I get the following output with a new linker error that it can't open main.obj.  I have not even begun working on the new linker error yet.  When I experimented with using the oneTBB libraries with the MSVC compiler, I started seeing the same error with not being able to use C++17 standard libs.  With MSVC, it builds with no issues if I do not include <tbb/tbb.h>.  If I include it, I get the same issue with not being able to use the c++17 standard libs.

Below is the code I used to generate this output.  As you can see, it is not terribly different from the above code. 

 

#include <tbb/tbb.h>
#include <numeric>
#include <filesystem>
#include <iostream>

int main()
{
int i = 14;
int j = 17;
std::cout << "Max is: " << std::max(i, j);
std::cout << "MSVC_LANG is: " << _MSVC_LANG << std::endl;

std::filesystem::path p;
return 0;
}

0 Kudos
RJM
Beginner
2,227 Views

Also note that I have so far only found this behavior when including <tbb/tbb.h>  I have spot checked including other files from tbb, such as <tbb/parallel_for> or <tbb/blocked_range3d.h> and have found no unusual or unexpected behavior from including them directly.  However, I still do have to use language standards for both MSVC and for ICC in order to get the expected behavior from IntelliSense.

0 Kudos
PrasanthD_intel
Moderator
2,173 Views

Hi Robert,


Thanks for the information and also for providing the logs.

We are working on it and will get back to you.


Regards

Prasanth


0 Kudos
Viet_H_Intel
Moderator
2,112 Views

The root cause of the issue is that the windows related headers defined the min and max function macros that are placed after the std:: prefix and caused the compilation error. The possible solution is to define the NOMINMAX macro.


The error is also seen if include windows.h

//#define NOMINMAX //fix the issue.


//#include <tbb/tbb.h> 

#include <windows.h>

#include <numeric>

#include <filesystem>

#include <iostream>



int main()

{

int i = 14;

int j = 17;

std::cout << "Max is: " << std::max(i, j);

std::filesystem::path p;

return 0;

}

C:\temp>icl test1.cpp /std:c++17

Intel(R) C++ Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.1.2 Build 20201208_000000

Copyright (C) 1985-2020 Intel Corporation. All rights reserved.


test1.cpp

test1.cpp(14): error: expected an identifier

 std::cout << "Max is: " << std::max(i, j);

                 ^


compilation aborted for test1.cpp (code 2)


C:\temp>cl test1.cpp /std:c++17

Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29333 for x64

Copyright (C) Microsoft Corporation. All rights reserved.


test1.cpp

test1.cpp(14): error C2589: '(': illegal token on right side of '::'

test1.cpp(14): error C2062: type 'unknown-type' unexpected

test1.cpp(14): error C2059: syntax error: ')'


C:\temp>


Thanks,



0 Kudos
Viet_H_Intel
Moderator
2,068 Views

Can we close this issue as it is not related to TBB?

Thanks,


0 Kudos
Viet_H_Intel
Moderator
2,045 Views

Hi,

We will no longer respond to this thread. If you require additional assistance from Intel, please start a new thread. Any further interaction in this thread will be considered community only.


Thanks,


0 Kudos
Reply