I would like to trying to help. I'm using yosemite now. I install dependency using macports, but und & gnu radio install by manually. Attach is the command that using llvm-gcc clang. They are run into same error, but I cannot telling why. And I try gcc4.9 install by macport didn't have the problem, but link boost will cause the error, I know I can install boost using gcc4.9, but it will cause I can not install one dependency (I forgot sorry) and/or can not compiler und correctly.
Using gcc, clang or llvm is more suitable for volk ? I have no idea, just know macports had a suggest that using gcc better than clang for volk. If there I can do to help, just tell me. Sincerely, Jeff Guo 2014-10-25 4:13 GMT+08:00 Stefan Oltmanns <stefan-oltma...@gmx.net>: > See: http://llvm.org/bugs/show_bug.cgi?id=9665 > When I understand that correctly it´s a bug in the intel avx header > files. The solution is either use other header files or do not use const > int, but literal values or enum. > > Best regards > Stefan > > > Am 24.10.2014 21:15, schrieb West, Nathan: > > 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 >
llvm
Description: Binary data
clang
Description: Binary data
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio