Bug #582

volk_test_all : volk_32fc_s32f_magnitude_16i_test fails on x86 and ARM for arch u_orc (v3.7.0)

Added by Tim Monahan-Mitchell over 1 year ago. Updated 8 months ago.

Status:ClosedStart date:08/12/2013
Priority:LowDue date:
Assignee:Tom Rondeau% Done:

0%

Category:volk
Target version:-
Resolution:

Description

Test fails on both x86 target (VMWare based) and on ARM target.

Tree set to v3.7.0 in both cases.

x86 Ubuntu 12.04; ARM Ubuntu 13.04, fpu=neon. More build environment details on request.

Subset of "ctest -V -R volk_test_all" for x86. Note the in1 values are all SHRT_MIN:

RUN_VOLK_TESTS: volk_32fc_s32f_magnitude_16i
1: a_sse3 completed in 0s
1: a_sse completed in 0s
1: generic completed in 0s
1: u_orc completed in 0s
1: offset 2 in1: -32768 in2: -26690
1: offset 3 in1: -32768 in2: -29682
1: offset 6 in1: -32768 in2: -23107
1: offset 14 in1: -32768 in2: -32041
1: offset 17 in1: -32768 in2: -31404
1: offset 24 in1: -32768 in2: -31028
1: offset 33 in1: -32768 in2: -26542
1: offset 39 in1: -32768 in2: -32764
1: offset 42 in1: -32768 in2: -20254
1: offset 49 in1: -32768 in2: -31936
1: volk_32fc_s32f_magnitude_16i: fail on arch u_orc
1: Best aligned arch: a_sse3
1: Best unaligned arch: generic
1: <work dir>/gnuradio/volk/lib/testqa.cc(39): error in "volk_32fc_s32f_magnitude_16i_test": check run_volk_tests(volk_32fc_s32f_magnitude_16i_get_func_desc(), (void (*)())volk_32fc_s32f_magnitude_16i_manual, std::string("volk_32fc_s32f_magnitude_16i"), 1, 32768, 20460, 1, 0, "NULL") == 0 failed [true != 0]

Same test snippet on ARM. Note more sensible in1 values which differ from in2 by 1:

RUN_VOLK_TESTS: volk_32fc_s32f_magnitude_16i
1: generic completed in 0s
1: u_orc completed in 0s
1: offset 2113 in1: 25715 in2: 25716
1: offset 2288 in1: -32187 in2: -32186
1: offset 2736 in1: 30211 in2: 30210
1: offset 4645 in1: -27740 in2: -27739
1: offset 5133 in1: 22809 in2: 22808
1: offset 5464 in1: 16620 in2: 16621
1: offset 5819 in1: 24881 in2: 24880
1: offset 6397 in1: 29365 in2: 29366
1: offset 6788 in1: -25326 in2: -25325
1: offset 8214 in1: 22687 in2: 22686
1: volk_32fc_s32f_magnitude_16i: fail on arch u_orc
1: Best aligned arch: generic
1: Best unaligned arch: generic
1: /src/gnuradio/volk/lib/testqa.cc(39): error in "volk_32fc_s32f_magnitude_16i_test": check run_volk_tests(volk_32fc_s32f_magnitude_16i_get_func_desc(), (void (*)()) volk_32fc_s32f_magnitude_16i_manual, std::string("volk_32fc_s32f_magnitude_16i"), 1, 32768, 20460, 1, 0, "NULL") == 0 failed [true != 0]

History

#1 Updated by Johnathan Corgan over 1 year ago

  • Status changed from New to Assigned
  • Assignee set to Tom Rondeau
  • Target version set to release-3.7.1

#2 Updated by Johnathan Corgan over 1 year ago

  • Target version deleted (release-3.7.1)

#3 Updated by Tom Rondeau about 1 year ago

I can confirm the problem and have a dev system set up to explore/debug it.

#4 Updated by Tom Rondeau about 1 year ago

  • Status changed from Assigned to Resolved
  • Resolution set to fixed

Not sure about the VMWare issue, but there are various SIMD oddities with the technology.

The ARM target problems were fixed by explicitly casting the tolerance variable in commit:
f627da1448f29e16a9b4d6e3cafcd2bd1bf1802b

#5 Updated by Johnathan Corgan about 1 year ago

  • Status changed from Resolved to Closed
  • Target version set to release-3.7.3

#6 Updated by Tom Rondeau about 1 year ago

  • Status changed from Closed to Feedback

This is still causing some issues. A few of us will work together this week to try and resolve it.

#7 Updated by Tom Rondeau 11 months ago

  • Target version deleted (release-3.7.3)

#8 Updated by Nathan West 11 months ago

There's a potential solution with mixed feedback in maint: b5b53e70cb782a6f0190fdccb167311fe65be10f

This seems to work OK on my armhf build. Tim's feedback from a similar commit that was merged in to maint is that it was still failing. I spent some time today getting a variety of boards set up so that I can test on ARM Linaro/Ubuntu images, OE softfp, and OE hardfp. I think I've got enough spare boards that I can leave these up and possible set up some automated testing (jenkins?) to catch more of these kinds of events.

This bug and 583 are definitely different symptoms of the same problem. The lowest level issue I've found is that volk/lib/qa_utils.cc:run_volk_tests(....) has a static_cast of the provided float tolerance to an int. The tolerance is also assigned to a float with a different name. It looks like in these specific cases neither assignment is happening. Printing the values out right after assignment forces values through int registers (because printf and cout are variadic functions).

#9 Updated by Tim Monahan-Mitchell 11 months ago

With the maint branch updated as of today (including the commit Nathan lists above), this Volk test now passes on my ARM target (I did not check with x86 VM build). Bug #583 still happens. Hat's off to Nathan for the progress!

#10 Updated by Tom Rondeau 8 months ago

  • Resolution deleted (fixed)

This bug only occurs on ARM with hard float ABI and looks specifically like an ORC bug:
https://bugzilla.gnome.org/show_bug.cgi?id=727464

It only affects the hard float ABI. We hope to be able to replace use of ORC by 3.8.

#11 Updated by Johnathan Corgan 8 months ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF