unintentional dead code elimination

[Francesco_F]

I verified an unintentional dead code elimination by the intel oneAPI C++ compiler (2025), working on a Windows machine. Same results compiling the code from Visual Studio, as well from the Intel oneAPI command line.

I think this is a bug (or misconfiguration on Windows?), or at least it should be considered a bug. From a linux machine there is no problem, the compilation error is found (Intel(R) oneAPI DPC++/C++ Compiler 2025.0.0 (2025.0.0.20241008)).

I verified this issue on two different windows machine.

An unintentional procedure like this may hide compilation errors in those part of the code that are not used.

Here is a an example code. From a linux cluster, intel compiler 2025 generate the expected compilation error:

 error: use of undeclared identifier 'thisbug' 

#include<array>
#include<iostream>

using my2array = std::array<double, 3>;
using my4array = std::array<double, 4>;

template <typename typey, typename typex>
class myOperator
{
public:
	void operator()(typey& Y, typex& X) const
	{
		// some good stuff
		std::cout << " We have some good stuff" << std::endl;
	}

	void operator()(typey& Y, typex& X, double alpha) const
	{
		thisbug = 5;
		std::cout << " We have some bad stuff" << std::endl;
	}
	
	
	void myfunction(typey& Y, typex& X)
	{
		thisbug = 5;
		std::cout << " We have some bad stuff" << std::endl;
	}

	myOperator(double mydouble, int myint) { // some initial good stuff
	}
};

int main(int argc, char* argv[])
{
	double a{ 5.5 };
	int b{ 2 };
	my2array arr2{ 1.0,3.0 };
	my4array arr4{ 7.0, 2.5, 1.3 };
	myOperator<my2array,my4array> myOp(a, b);

	myOp(arr2, arr4);
	//myOp.myfunction(arr2, arr4);  // uncomment this line to get an error from intel oneAPI compiler (Windows)
	//myOp(arr2, arr4,a);  // uncomment this line to get an error from intel oneAPI compiler (Windows)

	return 0;
}

Is this a bug? Are windows and linux intel oneAPI compiler really different?
Dead code elimination should not be OS dependent... I guess...

any help or comment is welcome.

[Francesco_F]

update:

• by using ISO C++20 Standard (/std:c++20) the bug is detected even from Windows (flag -std=c++17).
• by using C++17 Standard the bug is not detected from Windows. From a Linux cluster, using C++17 standards doesn't change: the bug is always detected.

[yzh_intel]

Hi,  I also see the error on Windows which is expected, could you try the latest compiler ?

>icpx -V
Intel(R) oneAPI DPC++/C++ Compiler for applications running on Intel(R) 64, Version 2025.0.4 Build 20241205
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

>icpx test.cpp
C:\tmp\test.cpp:26:3: error: use of undeclared identifier 'thisbug'
   26 |                 thisbug = 5;
      |                 ^
1 error generated.

[Francesco_F]

Hi, thank you for the message.

Here is what I see from Intel oneAPI command prompt for Intel 64 for Visual Studio 2022:

>"C:\Program Files (x86)\Intel\oneAPI\compiler\2025.0\bin\icpx.exe" -v
Intel(R) oneAPI DPC++/C++ Compiler 2025.0.4 (2025.0.4.20241205)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files (x86)\Intel\oneAPI\compiler\2025.0\bin\compiler
Configuration file: C:\Program Files (x86)\Intel\oneAPI\compiler\2025.0\bin\compiler\..\icpx.cfg

>"C:\Program Files (x86)\Intel\oneAPI\compiler\2025.0\bin\icpx.exe" test.cpp

>"C:\Program Files (x86)\Intel\oneAPI\compiler\2025.0\bin\icpx.exe" -std=c++17 test.cpp

>"C:\Program Files (x86)\Intel\oneAPI\compiler\2025.0\bin\icpx.exe" -std=c++20 test.cpp
\test.cpp:19:3: error: use of undeclared identifier
      'thisbug'
   19 |                 thisbug = 5;
      |                 ^
\test.cpp:26:3: error: use of undeclared identifier
      'thisbug'
   26 |                 thisbug = 5;
      |                 ^
2 errors generated.

So, I get the correct compilation error only if I use the flag -std=c++20.
My cpu is:

>wmic cpu get caption, deviceid, name, numberofcores, maxclockspeed, status
Caption DeviceID MaxClockSpeed Name NumberOfCores Status
Intel64 Family 6 Model 170 Stepping 4 CPU0 1300 Intel(R) Core(TM) Ultra 5 125U 12 OK

 OS:

OS Name:                   Microsoft Windows 10 Enterprise
OS Version:                10.0.19045 N/A Build 19045
OS Manufacturer:           Microsoft Corporation

Note that also your compiler didn't see the error at line 19.

[yzh_intel]

I only uncommented line 43, so the compiler only shows the error on line 26. If I also uncomment ln 44, the error at line 19 will show up. 

But I tried on a few machines, couldn't see your issue... I don't know if this is a corner case or due to some specific setup in your environment. Maybe someone else can chime in to see if this issue can be reproduced elsewhere. 

[Francesco_F]

Ok. I probably didn't write a clear message. My concern is that WITHOUT uncommenting those lines (i.e. leaving the code as it is), on my two Windows machines the Intel compiler does not give any error. But the errors are clearly there. Those errors are in parts of the code that are not used (that's why I wrote dead code elimination). IF I use the -std=c++20, then the errors are finally found. On a Linux cluster, the errors are correctly seen with both c++17 and c++20.

This may give many problems when collaborating to big projects. I'm not sure, but this may be called "dead code elimination" and I would not expect this "feature" to be activated by default, because it hides bugs. And I actually think that this could be a compiler bug.

[yzh_intel]

Hi, I can reproduce the behavior now, indeed there's some difference between the compilers on linux and windows. But this doesn't hurt anything for your sample code, after all what's deleted is dead code. Can you elaborate more on the scenario when collaborating on big projects and this can be problematic ? 

[Francesco_F]

Many thanks again.

So, at this point we may agree that:

 - the "dead code" is subjective to the user configuration: the dead code for user A may be non-dead code for user B (especially if A is using windows intel compiler and B is not);

 - this kind of windows compiler is hiding bugs (any kind of bugs).

Now, imagine that any of your colleagues is (unintentionally) pushing bugs to the joint branch of the project. When you pull the branch, in the best case you get a compilation error (not the best experience, but at least you see and localize the error), while in the worst case it may last a lot of time (days, weeks, months...) before finding the bug, and in the meantime the bugs may also accumulate. This causes a incredible loss of resources.

[yzh_intel]

Hi, thanks for your explanation, this behavior only affects template functions/classes on Windows, it was made in order to be compatible with MS compiler, which unfortunately is not very conformant to C++ standard.

To enable the errors you would like to see, please add option "-fno-delayed-template-parsing"