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

Reply via email to