Spurious warning: compiler bug ?

[carlox]

This happens with CVI 2010 SP1.

Compiling this code, I get  "Warning: Conversion from '__int64' to 'long' might lose data." on the "z = y" line.

Please note that line does not involve any __int64 variable.

More strange: If I comment any "case" line, the warning disappears: the warning appears when are present four or more "case" statements.

Nevertheless, the generated code works perfectly, at a quick test.

#define A 0x00000000
#define B 0x00000001
#define C 0x00000002
#define D 0x00000003

#define MASK 0x00000003

void CompilerBug()
{
__int64 x=0;

int y,z;

	switch(x & MASK) {
		case A: y=0; break;
		case B: y=1; break;
		case C: y=2; break;
		case D: y=3; break;
	}
	z = y;
}

I will be glad if someone can confirm this behaviour.

Thanks

[OVR_CZ]

hi carlox,

             there is missing semicolon after end of the switch statement }; which cause litle confusion about where the warning is pointed.

             The problem is that switch can only accept int values not int64. (The expresion "x & MASK" is by "automatic type conversion: converted to int64 value)

             to solve use re-typing to int:

switch((int)(x & MASK)) {
...
};

[carlox]

OVR_CZ, this is the first time in 25+ years that I hear that a switch statement needs a semicolon after.

In fact, the semicolon isn't needed, the selection statement ends with the closing curly bracket }.

Adding the semicolon after the switch simply adds an empty statement, and the warning is then attached to it.

The problem actually is the statement that warning message hilights.

The switch expression requirement is that it must have integral type.

As far as I know __int64 actually IS an integral type. 

So I expect that switch statement should compile without problem the __int64 expression.

(there are a 

By the way, if compile in 64 bit mode, there is no warning at all.

As far as I can see there are three problems, surely related each other:

1) the code line linked to the warning message is wrong

2) wrong conversion to long of the switch expression (casting the constant to __int64 does not has any effect)

3) misterious disappearing of any problem when the switch statement has three or less case labels

Just for better confusing the ideas

In 32 bit mode #defining BADBOY in the following code gives the problem, #defining GOODBOY instead

the following code works perfectly, zero warning and expected functionality.

In 64 bit mode, BADBOY gives zero compilation warning and a General Protection Fault on the switch(x) { line,

#include <utility.h>

#define BADBOY
//#define GOODBOY

#ifdef BADBOY
	#define A 0x11111000
	#define B 0x11111001
	#define C 0x11111002
	#define D 0x11111003
	#define E 0x11111004

	#define X 0x11111001
#endif

#ifdef GOODBOY
	#define A 0x00000000
	#define B 0x10000000
	#define C 0x20000000
	#define D 0x30000000
	#define E 0x40000000

	#define X 0x10000000
#endif

void CompilerBug(void);

void main()
{
	CompilerBug();	
}


void CompilerBug()
{
__int64 x = X;
int y;

	switch(x) {
		case A: y=10; break;
		case B: y=20; break;  
		case C: y=30; break;
		case D: y=40; break;
		case E: y=50; break;  
	} 
	
	DebugPrintf("y value is:%d\n",y);
}

[OVR_CZ]

     i am sorry, you are absolutely right about the "missing" semicolon. I do it for age and not know that this is unnescessary,maybe i am affected by this sort of warnings 🙂 ,

     also oficial requirement for switch is integral type, not int, so i thanks you again.

     It seems to me that you found new bug with 64bit variable.Maybe someone from NI check your post and create official issue.

P.S. unrelated but maybe interesting  to you, post message about other 64bit bug. http://forums.ni.com/t5/LabWindows-CVI/Please-explain-CVI-Issue-335358-Using-the-bit-shift-operator/...

[D_Biel · Accepted solution]

At first inspection, the warning appears to be bogus. The conversion from __int64 to long does not actually occur. Instead, the case expressions are converted from long to __int64. The behavior of the switch statement appears to be correct and so the warning can be ignored.

We have not investigated the cause of this error yet, but you can track the issue with bug ID 363456. In the meantime, it may be safest to ensure that your switch expression and case expressions are of the same type in case we have not fully defined all of the errors.