error generated by redefinition of __INTEL_LLVM_COMPILER

[David_Eberly]

I have Microsoft Visual Studio 2022 (17.4.2) and Intel oneAPI (HPC Kit 2022.3.1.19755, Base Kit 2022.3.1.19798). Running on Windows 11 Pro 22H2.  I retargeted a VS solution with multiple projects, choosing "Use Intel oneAPI DPC++/C++ Compiler". I executed a "rebuild solution." None of my projects compile successfully. I get errors

2>In file included from <built-in>:394:
2><command line>(3,9): : error : '__INTEL_LLVM_COMPILER' macro redefined [-Werror,-Wmacro-redefined]
2>#define __INTEL_LLVM_COMPILER 20220200
2> ^
2><built-in>(7,9): note: previous definition is here
2>#define __INTEL_LLVM_COMPILER 20220201

Is there some way I can work around this?

Thank you,

Dave Eberly

<email removed>

[David_Eberly]

It appears the problem occurs because of an installation issue. The Microsoft installed-apps dialog that shows an Intel oneAPI Base Kit  and an Intel HPC Kit installed on 10/5/2022 (presumably 2022.3.0 version). It also shows an Intel oneAPI Base Kit and an Intel HPC Kit installed on 11/10/2022 (presumably 2022.3.1 version). When I try to uninstall either version via Microsoft's dialog, an Intel dialog launches and gives me the ability to uninstall. The version number of oneAPI is the same in the Intel dialog whether I try to uninstall the 2022.3.0 version or 2022.3.1 version.

With both versions installed, perhaps the Intel compiler is accessing the wrong header directory in the "Program Files (x86)/Intel/oneAPI/compiler_ide" folder.

I am uninstalling all of oneAPI and will reinstall latest.

[David_Eberly]

Uninstalling all of oneAPI and installing only the latest does not solve the problem. I still get the same error about redefined macro __INTEL_LLVM_COMPILER.

[VidyalathaB_Intel]

Hi David,

Thanks for reaching out to us.

Could you please provide us with a sample reproducer so that we can have a quick check on our end?

Regards,

Vidya.

[David_Eberly]

The easiest thing to do is download the source code repository from my website: https://www.geometrictools.com/Downloads/GeometricTools6p5.zip 

1. Unzip the file. All header include paths are relative, so it does not matter where you place the root folder "GeometricTools".
2. In the subfolder "GeometricTools/GTE", open BuildAll.v17.sln. It will take a small amount of time to load all the project information.
3. Right-click the "Solution 'BuildAll.v17'" item. In the pop-up menu, go to "Intel Compiler". The options I see are "Use Intel C++ Compiler Classic", "Use Intel oneAPI DPC++/C++ Compiler", "Use Visual C++" and "Use Gcc".
4. Select "Use Intel oneAPI DPC++/C++ Compiler". A dialog is launched with the title "Use Intel oneAPI DPC++/C++ Compiler". It has "The selected solution/project(s) will be configured to use Intel C++ Compiler 2022."
5. Press the OK button. A small amount of time is required to change the toolset. In the Output window you will see messages such as  'Platform "x64" has been updated to use the Intel(R) oneAPI DPC++/C++ Compiler successfully.'
6. Press the Exit button in MSVS 2022 so that the changes are written to disk. A dialog is launched giving you the option to "Save", "Don't Save" or "Cancel". Press "Save".
7. In File Explorer, use a text editor to view GTApplicationsDX11.v17.vcxproj. You will see lines <PlatformToolset>Intel C++ Compiler 2022</PlatformToolset>. The toolset name is incorrect and appears to be the one associated with the deprecated Classic Compiler. If you try to build the solution, you get the macro-redefinition error I mentioned in my forum post.
8. Based on what I saw in the MSVS project settings for Platform Toolset, I modified the toolset name to "Intel(R) oneAPI DPC++ Compiler 2022". I actually did this with a program I wrote, GeometricTools/GTE/Tools/ChangePlatformToolset. If you use this tool, the configuration properties for Debugging must be modified. The Command Arguments should be "Intel(R) oneAPI DPC++ Compiler 2022" (the quotes are necessary) and the Working Directory should be <PATH>GeometricTools/GTE (where PATH is the location you unzipped the zip file to).
9. With the correct toolset name, the DPC++ compiler launches when you build BuildAll.v17.sln. The first project with source code is GTGraphics.v17. No information is generated in the Output window by the compiler for a long time, but Task Manager shows that MSVS and associated processes are running.
10. Unfortunately, when information is generated, all I get are error messages: "'__stdcall' calling convention is not supported for this target". This convention is used in my OpenGL extension wrapper code. The convention is also exposed in Windows Kits header files. For example, minwindef.h defines CALLBACK to be __stdcall and is exposed because _MSC_VER >= 800. I use CALLBACK in WNDPROC functions in my base-level application code, so none of my projects compile successfully.

[VidyalathaB_Intel]

Hi David,

Thanks for providing us with the details.

However, I'm unable to access the link that you provided in your post. Could you please attach the zip file here in the forum?

Regards,

Vidya.

[David_Eberly]

Hello Vidya.

Sorry, I misspelled the file name. It should be https://www.geometrictools.com/Downloads/GeometricToolsEngine6p5.zip . I also attached the file to this post. Thank you.

[VidyalathaB_Intel]

Hey David,

Thanks for sharing the details.

Actually, I've tried to reproduce the error that you are getting with a small code in VS and when I retargeted an existing VS project file in my system as how you did, I could see that message '__INTEL_LLVM_COMPILER' macro redefined but in my case, it is just a warning as I disabled the option Turn warnings as errors in configuration properties > C++ > General path. Maybe you can also try it once and see if that doesn't affect your final output

Please get back to us if you have any issues in doing so.

Regards,

Vidya.

[David_Eberly]

Hello Vidya.

Disabling "treat warnings as errors" is something I do not do with my code distribution. I try to make my code as compliant with the C++ standards as I can. Having the option enabled also can find cases where the warning really can become an error at runtime (for example, comparisons of signed and unsigned integers). My code base also compiles and runs on various Linux distributions. I also enable "treat warnings as errors."

The correct solution is to fix your MSVS extension to use the correct Platform Toolset name.

The work-around I can use now is to run my tool that changes the Platform Toolset name to the correct one. The solutions has 327 projects, so I am certainly not going to do that manually. My goal is to ensure my code base compiles on the Windows platform using Microsoft's compiler, the Clang-CL (LLVM) compiler and Intel's compiler because I have programmers who use my code distribution with these compilers.

So... I have a work-around for setting the correct Platform Toolset name. But as my reproducer steps show (see step 10), I still cannot compile because of the supposed lack of support for __stdcall. Have you tried to reproduce this?

Thank you for your time in looking into this,

David

[VidyalathaB_Intel]

Hey David,

Thanks for getting back to us.

>>Have you tried to reproduce this?

Surely I'll try to reproduce the issue with the provided information and I'll get back to you in case I have any doubts about reproducing it.

In meantime, I thought of giving you my findings which I come across when retargeting the VS project and I just want to let you know.

I'll get back to you as soon as I reproduce the issue.

Regards,

Vidya.

[David_Eberly]

I have posted a trimmed down reproducer. I modified the Platform Toolset name to be the correct one. But to be sure, I also disabled "Treat warnings as errors".

Unzip the zip file. Open the solution GeometricTools/GTE/GTGraphicsGL45.v17.sln. Build the solution. It still takes some time for DPC++ to display the output error messages. These messages are all about __stdcall not supported.

Here is my dilemma.

1. The Intel Compilers are integrated into MSVS 2022, specifically the ability to select DPC++ from the MSVS IDE.
2. DPC++ requires MSVS 2022 to be installed, apparently because it uses the clang-cl.exe component.
3. DPC++ uses the Standard C++ Library from MSVS 2022, and it has to access the Windows SDK (via Windows Kits).
4. The MSVS IDE has a macro _MSC_VER that, when larger or equal to 800, exposes __stdcall by way of macros APIENTRY, WINAPI and CALLBACK. Because MSVS 2022 has _MSC_VER larger than 800, __stdcall is exposed.
5. DPC++ does not support __stdcall.

These items seem to imply that it is impossible to use DPC++ from within the MSVS IDE.

I removed the hard-coded use of __stdcall from my OpenGL extension wrapper (in GeometricTools/GTE/Graphics/GL45/GL45.h). I also deleted the CALLBACK macro in my application layer (in GeometricTools/GTE/Applications/MSW/WindowSystem.{h,cpp}, function static LRESULT WindowProcedure(HWND,UINT,WPARAM,LPARAM) that used to have CALLBACK before WindowProcedure). The compile still fails. The OpenGL header glcorearb.h that Khronos ships (in GeometricTools/GTE/Graphics/GL45/GL) exposes __stdcall because APPENTRY is defined (indirectly) from Windows.h. I would have to modify the Khronos headers as a work-around. But if I were to do this, nothing changes the fact that __stdcall is exposed (in minwindef.h of the Windows SDK) via WINAPI, the latter symbol occurring frequently in the Windows SDK.

All I can conclude from my experiments is that it is not possible to use DPC++ in the MSVS 2022 IDE. If you can verify my conclusion or let me know whether my analysis is flawed, I will appreciate it. I will try to find another way to support DPC++.

Thank you,

David

[David_Eberly · Accepted solution]

I received an email that Intel oneAPI version 2023.0 is available. I uninstalled the previous version and then installed the new version. The "macro redefinition" warning no longer occurs. After further investigation, selecting "Use Intel C++ Compiler Classic" leads to platform toolset "Intel C++ Compiler 19.2" and selecting "Use Intel oneAPI DPC++/C++ Compiler" leads to platform toolset "Intel C++ Compiler 2023". With this toolset, my code compiles without warnings (and "Treat warning as errors" is enabled). When I use my tool to set the platform toolset "Intel oneAPI DPC++ Compiler 2023", the code does not compile because of the presence of __stdcall. I suppose this makes sense in that "Intel C++ Compiler 2023" is general purpose and can compile Windows-API-based code (with __stdcall), but the DPC++ compiler is specific to performance of non-Windows-API code.

I can let users of my code know that Intel C++ Compiler 2023 is supported. The only code that benefits from DPC++ would be my mathematics code, but that library is header-only and is mostly template code.

Thanks for the time you spent looking into this.

David Eberly

[VidyalathaB_Intel]

Hi David,

Thanks for letting us know and glad to know that your issue is resolved with the latest release of oneAPI.

As the issue is resolved we are closing this thread. Please post a new question if you need any additional assistance from Intel as this thread will no longer be monitored.

Have a Nice Day!

Regards,

Vidya.