Modify

Ticket #8665 (closed Bugs: fixed)

Opened 11 months ago

Last modified 7 months ago

Unreachable code warnings in variant.hpp - msvc

Reported by: hvemha@… Owned by: ebf
Milestone: To Be Determined Component: variant
Version: Boost 1.53.0 Severity: Problem
Keywords: Cc: antoshkka@…

Description

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

Attachments

variant.hpp.patch Download (641 bytes) - added by hvemha@… 8 months ago.
Suggested patch

Change History

comment:1 Changed 11 months ago by apolukhin

  • Cc antoshkka@… added

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?

comment:2 follow-up: ↓ 3 Changed 11 months ago by 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.

comment:3 in reply to: ↑ 2 Changed 11 months ago by apolukhin

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.

comment:4 Changed 8 months ago by 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...

Changed 8 months ago by hvemha@…

Suggested patch

comment:5 Changed 7 months ago by apolukhin

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

comment:6 Changed 7 months ago by apolukhin

  • Status changed from new to closed
  • Resolution set to fixed

(In [85882]) Merge from trunk:

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

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.