Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?

[Monahan-Mitchell, Tim]

Just for the record.

>> If the selected floating-point hardware includes the NEON extension (e.g. 
>> -mfpu='neon'), note that floating-point operations are not generated by 
>> GCC's auto-vectorization pass unless -funsafe-math-optimizations is also 
>> specified. This is because NEON hardware does not fully implement the IEEE 
>> 754 standard for floating-point arithmetic (in particular denormal values 
>> are treated as zero), so the use of NEON instructions may lead to a loss of 
>> precision.
 
Regarding loss of precision: my target is able to use '-mfpu=neon-vfpv4' which 
selects floating point  fused operations instead of chained. I tried it, but a 
new test error surfaces due to accuracy (v3.7.0):

/src/gnuradio/build # ctest -V -R qa_ofdm_frame_equalizer_vcvc
UpdateCTestConfiguration  from :/src/gnuradio/build/DartConfiguration.tcl
UpdateCTestConfiguration  from :/src/gnuradio/build/DartConfiguration.tcl
Test project /src/gnuradio/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 142
    Start 142: qa_ofdm_frame_equalizer_vcvc

142: Test command: /bin/sh 
"/src/gnuradio/build/gr-digital/python/digital/qa_ofdm_frame_equalizer_vcvc_test.sh"
142: Test timeout computed to be: 9.99988e+06
142: .....F.
142: ======================================================================
142: FAIL: test_002_static (__main__.qa_ofdm_frame_equalizer_vcvc)
142: ----------------------------------------------------------------------
142: Traceback (most recent call last):
142:   File 
"/src/gnuradio/gr-digital/python/digital/qa_ofdm_frame_equalizer_vcvc.py", line 
244, in test_002_static
142:     self.assertEqual(tag_dict, expected_dict)
142: AssertionError: {'frame_len': 4L, 'ofdm_sync_chan_taps': [0j, 0j, 
(-2.2037331959268158e-08+1j),  [truncated]... != {'frame_len': 4, 
'ofdm_sync_chan_taps': [0, 0, 1j, 1j, 0, 1j, 1j, 0]}
142: + {'frame_len': 4, 'ofdm_sync_chan_taps': [0, 0, 1j, 1j, 0, 1j, 1j, 0]}
142: - {'frame_len': 4L,
142: -  'ofdm_sync_chan_taps': [0j,
142: -                          0j,
142: -                          (-2.2037331959268158e-08+1j),
142: -                          (-2.2037331959268158e-08+1j),
142: -                          0j,
142: -                          (2.2037331959268158e-08+1j),
142: -                          (-2.2037331959268158e-08+1j),
142: -                          0j]}

So I went back to just '-mfpu=neon'.

I didn't log this as a GR bug, since it feels like the "Doctor, it hurts when I 
do this" variety of problems.