saturating arithmetic errors in x86_64(due to avx2?)

[kraiskil]

Tests 5 and 11 fail unexpectedly on one x86_64 Ubuntu 12.04 installation. The only difference to several working similar installations that I can think of is that this machine is a haswell, i.e. has avx2 instructions.
Tested with LLVM 3.3 only.
Marked as XFAIL in 2150cd1.

[pjaaskel]

Can you try what I did when debugging https://bugs.launchpad.net/pocl/+bug/1179211
i.e. switch off the avx2 and see if it still breaks? Then it's easier to isolate and report a bug to LLVM.

[pjaaskel]

Did you report this to LLVM? Perhaps testing with LLVM 3.4 should be done first to see if they have fixed it already.

[kraiskil]

I didn't take time to isolate this yet. I should, before 3.4 is frozen... And no, it is not fixed yet, as of last week at least.

[kraiskil]

Just to save the intermediate result: seems the issue is with the select() function in (e.g.)

short16 convert_short16_sat(float16 x) {
short16 y = convert_short16(x);
y = select(y, (short16)SHRT_MIN, convert_short16(x < (float16)SHRT_MIN));
y = select(y, (short16)SHRT_MAX, convert_short16(x > (float16)SHRT_MAX));
return y; }

for an input of splatted -2.0f, the value of y in this function is:
y.x = fffffffe
y.x = ffff8000
y.x = 7fff
The first one is correct.

After the first line, y is correct, after the second, it is wrong.

[kraiskil]

Isolated the issue further: https://gist.github.com/kraiskil/7431748
running the shell script:
£./run.sh core-avx-i
res1.x=a, res2.x=a
£./run.sh core-avx2
res1.x=b, res2.x=b

If the comparison in myselect is <= instead of < both targets return the same (correct) value.

[pjaaskel]

OK, time for an LLVM bug report? Might get fixed before LLVM 3.4.

[kraiskil]

Good point :) http://www.llvm.org/bugs/show_bug.cgi?id=17899

[kraiskil]

Strangely, the fix in 9e5b831 for issue #39 seems to fix both issues. Removed XFAILs in commit above.
Also, the OpenCL-C code above has implementation defined behaviour (issue #34), but the LLVM bug report seems still valid, though. I guess the reduction sidetracked and found a new bug?
Leaving this issue open until the LLVM bug is resolved.

[pjaaskel]

Is this resolved?

[pjaaskel]

Assuming fixed.