Intel compiler bug?

[Rein Halbersma]

Code: Select all

...
	vector< PackedColor > hmap&#40; 256 );
	for ( int i=0; i<256; i++ ) &#123;
		hmap&#91;i&#93;.packed = 128*256;
	&#125;
	int h = 256 * hmap&#91;0&#93;.GetG&#40;);
	// expect 32768 here but get 0
	cout << "h=" << h << endl;
	return 0;
&#125;

All the for loop stuff is usually folded away (in these simple cases) since you are accessing only the first element. The compiler then keeps only

Code: Select all

int h = 256 * hmap[0].GetG();

which produces 0, because GetG() returns an uchar that will be shifted left by 8 bits, leaving you with 0 as result... as expected!

No, the uchar has to be promoted to uint before multiplication or shifting

[xmas79]

Code: Select all

movzx esi,byte ptr [esi]
and esi,0FFFFFF00h

I see... But what is the "and" supposed to do? Can you post all the relevant assembly?

EDIT:
thinking about it, where does esi points to? maybe it points directly to the right byte? But I still miss the and part...

[xmas79]

Why don't you look at generated assembly? With 257 the compiler emits a multiply instruction. The 256 instead is probably optimized as left shift, and extra care could be needed (to prevent the compiler bug)?

I don't want to prevent the bug, I want it gone!
Assembly:

Code: Select all

movzx esi,byte ptr [esi]
and esi,0FFFFFF00h

Anyway it fetches the first byte instead of second (x86 is little endian).

This is what MSVC says about it:

Code: Select all

mov         rdi,qword ptr [hmap]
...
movzx       ebx,byte ptr [rdi+1]
shl         ebx,8

[mar]

I see... But what is the "and" supposed to do? Can you post all the relevant assembly?

EDIT:
thinking about it, where does esi points to? maybe it points directly to the right byte? But I still miss the and part...

esi points to the first element of the vector.
I think it indended this (unaligned is ok on x86):

Code: Select all

movzx esi,word ptr [esi]
and esi,0FFFFFF00h

But I'd probably prefer this

Code: Select all

movzx esi, byte ptr [esi+1]
shl esi, 8

You don't want me post the whole assembly here

[xmas79]

...
I think it indended this (unaligned is ok on x86):

Code: Select all

movzx esi,word ptr [esi]
and esi,0FFFFFF00h

But I'd probably prefer this

Code: Select all

movzx esi, byte ptr [esi+1]
shl esi, 8

...

Yes, "now" they are equivalent... Filed the bug?

[mar]

Yes, "now" they are equivalent... Filed the bug?

Yes, waiting for response, they wanted something reproducible so I sent the code above. But it's possible it's been already fixed in the latest version (which I don't have).
Still I find it really scary, imagine an important system compiled with icc and this bug triggering in some rare path not covered by tests...

[xmas79]

Quite expensive.... $699 for a single developer "base" license...

[mar]

Quite expensive.... $699 for a single developer "base" license...

Yes, considering it's buggy

[Bloodbane]

Parallel Studio XE13 was free on Linux with a non-commercial license. Some day XE15 will be the same.

https://software.intel.com/en-us/non-co ... evelopment

[mar]

The bug has been confirmed by Intel support and passed to engineering (reproducible in XE 15 as well).