Bug 1161119

Created attachment 954427 [details]
Tests fix

Failing tests:
"QCOMPARE(rm.getValueForPositionUnclamped(0), 0.0);
QCOMPARE(rm.getValueForPositionUnclamped(9), 0.0);"

in TestRangeMapper.h with:

"
.
.
.
FAIL!  : TestRangeMapper::linearUpBackward() Compared doubles are not the same (fuzzy compare)
   Actual   (rm.getValueForPositionUnclamped(0)): -2.23517e-08
   Expected (0.0)                               : 0
   Loc: [o/../TestRangeMapper.h(80)]
FAIL!  : TestRangeMapper::linearDownBackward() Compared doubles are not the same (fuzzy compare)
   Actual   (rm.getValueForPositionUnclamped(9)): -2.23517e-08
   Expected (0.0)                               : 0
   Loc: [o/../TestRangeMapper.h(96)]
.
.
.
"
Tests fail due QCOMPARE is using qFuzzyCompare to compare floats internally, which may fail when one of a compared value is 0.0(documented behaviour, but bit perplexing as it's not affecting x86 in this case, probably rounding error...).

QT docs/bug:
http://qt-project.org/doc/qt-5/qtglobal.html#qFuzzyCompare-10
http://qt-project.org/doc/qt-5/qtest.html#QCOMPARE
https://bugreports.qt-project.org/browse/QTBUG-16819

Proposed workaround from documentation is not working, as it results in 1!=1. But using qFuzzyIsNull(undocumented, but used/recommended(see up mentioned bug)) in combination with QVERIFY result in tests pass on all Fedora kojis.

Scratch builds with patch:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8053247
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1601344
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2172191
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2774957

In attachment is patch doing these changes.