The intel docs specify that function as taking a const int, so I'm not sure why that wouldn't work but the literal value would. Although I'm basically fine with using the literal value, I feel like the "correct" thing to do is use a const int here. At a minimum I'd like to at least understand what's happening.
* Is this caused by a specific version of clang that is introduced by the OS upgrade? (aka can I install a version of clang to test this on linux) * Are there some "be super strict about const parameters" flags being passed in that haven't been previously? * Is there some compiler cache issue that caused your const change to be silently ignored? If you're willing to test #3 that would be great. If you can provide a command line used to compile (make VERBOSE=1 > file; parse file for this build command) and a clang version I might be able to tinker with this. I'm assuming here that clang on Macs is not modified from the publicly available clang (I don't actually know if that's true or not). Nathan On Thu, Oct 23, 2014 at 7:57 PM, Michael Dickens <michael.dick...@ettus.com> wrote: > Oh goody! I have a MacPorts ticket with this issue, and my AVX Mac is > currently unavailable for fixing this. Maybe somebody (Nathan? Tom?) can > figure out the correct fix? - MLD > > On Oct 23, 2014, at 1:52 PM, Stefan Oltmanns <stefan-oltma...@gmx.net> wrote: > >> Adding const did not fix the problem, so I gave the 0xdd / 0x88 directly >> as shuffle mask parameter in _mm256_shuffle_ps, then it compiles without >> any problems (same fix for volk_32fc_deinterleave_imag_32f.h) > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
