Latest Gnuradio git won't compile on OS X

I just got the latest git version of gnuradio and tried to compile, but
I get compilation errors resulting from avxintrin.h:

These errors seems to be common and result from using non-standard
GCC-extensions that clang does not support.

Any ideas?

On Thu, Oct 23, 2014 at 12:37 PM, Stefan O.
[email protected] wrote:

I just got the latest git version of gnuradio and tried to compile, but
I get compilation errors resulting from avxintrin.h:

GNURadio OS X compilation error - Pastebin.com

These errors seems to be common and result from using non-standard
GCC-extensions that clang does not support.

Any ideas?

This is a recently introduced bug; thanks for the report!

This is apparently because clang is stricter than gcc on constant
arguments. The shuffle parameter is defined as an int rather than
const int. The same instruction/function has been used for a long time
without any problems, but in other cases we always give the literal
value rather than a variable.

Since you’re building from source I’ll assume you might be able to try
this patch out:

— a/volk/kernels/volk/volk_32fc_deinterleave_32f_x2.h
+++ b/volk/kernels/volk/volk_32fc_deinterleave_32f_x2.h
@@ -42,8 +42,8 @@ static inline void
volk_32fc_deinterleave_32f_x2_a_avx(float* iBuffer, float* qB

unsigned int number = 0;
// Mask for real and imaginary parts

  • int realMask = 0x88;
  • int imagMask = 0xdd;
  • const int realMask = 0x88;
  • const int imagMask = 0xdd;
    const unsigned int eighthPoints = num_points / 8;
    __m256 cplxValue1, cplxValue2, complex1, complex2, iValue, qValue;
    for(;number < eighthPoints; number++){

Otherwise, just roll back to a commit before we merged in the volk
gsoc work (1-2 weeks, I think).

Nathan

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)

Thank you very much
Stefan

Am 23.10.2014 19:50, schrieb West, Nathan:

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

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 D.

See: 9665 – __builtin_shufflevector requires a constant integer
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:

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 O. [email protected]:

I just fixed this issue within MacPorts <
Changeset 127653 – MacPorts >, which will be live by
around 12:30 PM/US/Eastern. I ended up following Stephans lead and
moving the shuffle index values directly into the function call; nothing
else made clang happy. Given that these constants are used just once,
and other constants are used in other shuffle calls directly, I think it
makes sense to just commit this change to GIT. The patch (-p0) is found
at <
patch-volk-shuffle.diff in trunk/dports/science/gnuradio/files – MacPorts

for anybody interested. For folks using MacPorts, youll want to do:
{{{
sudo port clean gnuradio*
sudo port selfupdate
}}}
before installing or upgrading whichever gnuradio port youre using (next
or devel; none of the others are affected). - MLD

That looks like the exact same error and will have the exact same
resolution. We’ll fix it before the next release. If you don’t feel
comfortable making the changes discussed in this thread then I suggest
you stick with a package manager (macports) and heed Michael D.’
advice:
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-10/msg00344.html


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio