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
>

Attachment: llvm
Description: Binary data

Attachment: clang
Description: Binary data

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to