Unreachable code warnings in variant.hpp - msvc

[hvemha@…]

This code produces C4702 warnings when compiled with warning level 4 and optimization enabled (/W4 and /O2). Tested with both VC10 and VC11.

#include "boost/variant/variant.hpp"

int main()
{
	boost::variant< int, double> a, b;

	if ( a < b )
	{
		return 1;
	}

	return 0;
}

d:\development\include\boost\variant\variant.hpp(353) : warning C4702: unreachable code d:\development\include\boost\variant\variant.hpp(353) : warning C4702: unreachable code d:\development\include\boost\variant\variant.hpp(1017) : warning C4702: unreachable code d:\development\include\boost\variant\variant.hpp(1017) : warning C4702: unreachable code

[Antony Polukhin]

Tested on boost 1_54_0_beta1 and this looks more like a visual studio bug. In debug mode we do reach that code. But in release mode Visual studio inlines all the function calls and complains on function that is actually called.

Unfortunately I fail to reproduce this issue without boost::variant. Can you?

[hvemha@…]

Not sure about the warning on line 1017. Only got this when building from the command line: cl /W4 /O2 Test.cpp

A default C++ project in Visual Studio and only changing the warning level in release build produces 4 C4702 warnings about line 353 for code.

It is clearly a bug to reach this line. I think it is the return and not the function all producing the warning. Probably an issue with the compiler (inline and __declspec(noreturn)?).

Also not sure what you mean by without boost::variant? operator< and operator== instantiates know_get, and this in turn results in the warnings on line 353.

Is it possible to just disable the C4702 warning in the never to be called operator()(U&)? It should be OK in this case.

[Antony Polukhin]

Replying to hvemha@…:

Not sure about the warning on line 1017. Only got this when building from the command line: cl /W4 /O2 Test.cpp

This is the only warning I can reproduce on my visual studio. My previous message was about it.

A default C++ project in Visual Studio and only changing the warning level in release build produces 4 C4702 warnings about line 353 for code.

Can not reproduce it on visual studio 11. May be it disappears after some updates of visual studio? My version is 11.0.60315.01 Update 2. What's yours?

Also not sure what you mean by without boost::variant? operator< and operator== instantiates know_get, and this in turn results in the warnings on line 353.

Usually all compiler developers require simplified version of code to reproduce compiler issue. Such code shall not include additional third party headers (variant.hpp) and shall contain minimal amount of code.

Is it possible to just disable the C4702 warning in the never to be called operator()(U&)? It should be OK in this case.

It is OK if this warning can not be fixed by code modifications. I'm just trying to figure out how to reproduce it, does MS know about that issue, is that really an issue, how can it be reproduced outside Boost.

[hvemha@…]

The warning on line 1017 is supressed by defining NDEBUG (adding /D NDEBUG to the command line). I’m not too concerned about this as NDEBUG should be defined when creating optimized builds.

I used the same version (now on update 3). The warning is also produced by earlier versions of the VC.

This simple code will produce the warning:

__declspec(noreturn)
void no_return() {}

int call_no_return() { no_return(); }

int main(int argc, char**)
{
	if( argc > 0 )
	{
		return call_no_return(); // warning C4702
	}
	return 7;
}

I guess the warning is related to assigning the return value of call_no_return to a variable in main scope (in an intermediate compiler language?), and not the function call.

Looking at the machine code it looks like the optimizer will assume the function never returns when declared with __declspec(noreturn). The optimizer change the above code to "return 7;", but if a side effect is introduces into no_return, the behaviour is undefined (typically a crash when returning from no_return as the compiler has not included the required instructions). In non-optimized builds the compiler ignores the noreturn declaration and generates instructions as if the function will/can return.

In my opinion the compiler is correct to issue the warning (the programmer has told the compiler that the function will not return).

Note: the fact that the compiler changes my example code to "return 7;" is also OK as for argc > 0 the behaviour is undefined...

[hvemha@…]

Suggested patch

[Antony Polukhin]

(In [85876]) Fix unreachable code warning, thanks 'hvemha' for providing it (refs #8665)

[Antony Polukhin]

(In [85882]) Merge from trunk:

• Add some merge infos
• Fix unreachable code warning (fixes #8665)