Bug #2826


osmo-trx: different output in convolve test between x86 vs neon vs neon-vfpv4

Added by pespin about 5 years ago. Updated almost 4 years ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


I attach the output while running convolve_test (previously in utils/ directory) on a x86 with ssse3 and sse4.1. Now that I am implementing the infrastructure to run tests in ARM (see #2721), I found out that the output for this test is different in neon and neon-vfpv4 cases. The output is also different between the 2 neon ones. The arm testsuite.log files contains the diff aginst the x86 one (as it was the first one I used and the tool was initially wrote against it, it's the "expected" output").

I don't know if that's expected or if it's actually a bug. Assigning to Tom as he seems to be the one knowing more about this topic and who wrote the initial code for ARM.


testsuite.log-neon testsuite.log-neon 2.86 KB pespin, 01/11/2018 05:14 PM
testsuite.log-neon-vfpv4 testsuite.log-neon-vfpv4 7.02 KB pespin, 01/11/2018 05:15 PM
convolve_test.ok convolve_test.ok 7.6 KB pespin, 01/11/2018 05:15 PM

Related issues

Related to OsmoTRX - Bug #2721: OsmoTRX build verification job for armResolvedpespin12/07/2017

Related to OsmoTRX - Bug #2828: some osmo-trx tests failing in i586 OBS machineResolvedtnt01/13/2018

Actions #1

Updated by pespin about 5 years ago

  • Related to Bug #2721: OsmoTRX build verification job for arm added
Actions #2

Updated by pespin about 5 years ago

  • Related to Bug #2828: some osmo-trx tests failing in i586 OBS machine added
Actions #3

Updated by ttsou about 5 years ago

I still need to look into the specific numbers as well as reproduce the issue locally, however, I suspect the issue relates to IEEE-754 floating point conformance.

The ARMv7 NEON instruction set is not IEEE-754 compliant, which can very well lead to inconsistent floating point output across builds.

An interesting question would be if the test fails on ARMv8 where the NEON instruction set is IEEE-754 compliant.

I will have more details shortly.

Actions #4

Updated by pespin about 5 years ago

Thanks for looking into it. If you have time and didn't see it yet, please read

Actions #5

Updated by pespin over 4 years ago

ttsou friendly ping in case you forgot about this topic :-)

Actions #6

Updated by laforge over 4 years ago

  • Assignee changed from ttsou to tnt
Actions #7

Updated by laforge about 4 years ago

  • Priority changed from Normal to High
Actions #8

Updated by tnt about 4 years ago

  • Status changed from New to In Progress

Looking at that now ...

I mean direct exact text compare for such kind of test is never going to work because of the IEEE precision ... sometimes because of non-perfect compliant operation, or because we purposefully do a faster less precise operation, or because operations in different orders, ... and so in either case you convole_test should have the test vector and expected results built-in and do the compare internally tolerating small deltas (sometime like X% deviation + a small epsilon).

But looking at the logs posted, some of the deviations seems a bit large, so I'll be checking that first.

Actions #9

Updated by tnt about 4 years ago


- Removed unused / unsupported features from the codebase
- Reworked the convole_test utility to be more useful and consistent across platform
- That new test utility actually uncovered a bug in the neon vfp4 implementation, so fixed that.
- Re-enabled convolve_test by default.

All pushed on gerrit for review.

Actions #10

Updated by tnt almost 4 years ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)