GNOME Bugzilla – Bug 728129
exec_opcodes_sys test fails on Intel i7-2620M when built with clang 3.5
Last modified: 2017-12-01 06:43:25 UTC
Created attachment 274209 [details] orc-bugreport.log See attached output of the test and orc-bugreport. Happens with git master, .17 and .18 at least. Didn't test earlier versions.
Created attachment 274210 [details] exec_opcodes_sys.log
Works when building with gcc 4.9, fails when building with clang 3.5
Fixed half of it already
The remaining problem here is the convdl and convfl code. The result of casting a float/double to an integer is undefined if the integral part of the float/double can't be represented by the target integer type. gcc apparently casts everything to 0x80000000 according to the existing code, clang to 0x00000000 or 0x80000000 depending on the phase of moon. Adding this check to the code > else if (tmp == 0 && (var32.f > 1.0 || var32.f < -1.0)) tmp = 0x7fffffff fixes it for most cases. The only remaining problem is that clang returns 0x80000000 in some cases for huge negative numbers, and the check above does not catch that > if (tmp == 0x80000000 && !(var32.i&0x80000000)) tmp = 0x7fffffff because the sign bit is set in the float. We could add another check that automatically changes floats > MAX or < MIN to 0x7fffffff but even then I wouldn't be surprised if the behaviour of the various SIMD instructions to do this conversion is different for the undefined case. What should we do here?
(In reply to comment #4) > We could add another check that automatically changes floats > MAX or < MIN to > 0x7fffffff but even then I wouldn't be surprised if the behaviour of the > various SIMD instructions to do this conversion is different for the undefined > case. Actually that already does not work. Huge negative numbers are currently expected to be cast to -0 and huge positive numbers to 0x7fffffff.
And even that does not work properly with the audioconvert test, only the internal orc tests. > else if (%s > 9223372036854775807.0) tmp = 0x7fffffff; > else if (%s < -9223372036854775808.0) tmp = 0;
With the released version, I still had this and other test problem with gcc on i686-linux. https://bugzilla.gnome.org/show_bug.cgi?id=735273 (unfortunately I didn't notice this report before creating the other one)
*** Bug 739776 has been marked as a duplicate of this bug. ***
Created attachment 293606 [details] bug report from tegra k1 bug report tegra k1 (neon) with gcc-4.9
Ping Is this still an issue with current orc master ?
Yes, nobody fixed anything further since Wim fixed a few of these issues.
I'd consider this a blocker now, with clang becoming much more common and compilers becoming more irrational with regard to undefined behaviour.
no longer the case ?
Yes, seems to have been fixed at some point by something. We still make use of undefined behaviour in the ORC C code though, but there's another bug for that.
Created attachment 364715 [details] FAIL exec_opcodes_sys: orc-0.4.28 + i686-linux + gcc-6.4.0 This doesn't happen on any of my machines with direct access (tried a few times), like https://bugzilla.gnome.org/show_bug.cgi?id=735273#c9 This should be on Dell r815, containing 4x12-core Opterons (most likely 61xx, k10 arch).