Re: [Discuss-gnuradio] MacOS, AVX, GCC, and LLVM

[Tom Rondeau]

On Sat, May 5, 2012 at 2:16 PM, Jared Boone <address@hidden> wrote:
> I spent some time last night getting the the development branch of GNU Radio 
> to compile on MacOS X 10.7. In the process, I saw some people having issues 
> with compiler/assembler AVX support, Apple's ancient GPLv2 "as", and Xcode's 
> LLVM. I succeeded in building and running GNU Radio using Xcode 4.3.2's tools 
> (no MacPorts gcc, llvm, or cctools). I'm posting what I learned, in hopes 
> somebody knows how to fix this from the GNU Radio source side (instead of 
> patching CMake, as I did).
>
> The problem I saw, having to do with Clang compiler flag detection for ORC 
> during cmake:
>
>    -- Performing Test have_maltivec
>    -- Performing Test have_maltivec - Success
>    -- Performing Test have_mfpu_neon
>    -- Performing Test have_mfpu_neon - Success
>    -- Performing Test have_mfloat_abi_softfp
>    -- Performing Test have_mfloat_abi_softfp - Success
>    -- Performing Test have_funsafe_math_optimizations
>    -- Performing Test have_funsafe_math_optimizations - Success
>    ...
>    -- Performing Test have_mpopcnt
>    -- Performing Test have_mpopcnt - Success
>
> Note that I'm compiling on a Sandy Bridge Intel processor, so Altivec (PPC), 
> NEON (ARM), and float-ABI (ARM?) aren't available. Also, LLVM 3.0 doesn't 
> support -mpopcnt, and apparently doesn't support -munsafe_math_optimizations. 
> And yet, the detections are showing "Success". Sure enough, when I "make", 
> volk bombs out with:
>
>    cc1: error: unrecognized command line option "-mfpu=neon"
>    cc1: error: unrecognized command line option "-mfloat-abi=softfp"
>
> Examining build/volk/CMakeFiles/CMakeOutput.log, the command line executed 
> for detecting the Altivec flag is:
>
>    /usr/bin/c++    -Dhave_maltivec   -maltivec -o 
> CMakeFiles/cmTryCompileExec.dir/src.cxx.o -c 
> /Users/jboone/tmp/gnuradio/build/volk/CMakeFiles/CMakeTmp/src.cxx
>
> Creating my own src.cxx ("int main() { return 0; }") and trying this out 
> yields:
>
>    clang: warning: argument unused during compilation: '-maltivec'
>
> Clang warns about the unrecognized flag, but CMake doesn't consider it an 
> error. Why? Examining volk/lib/CMakeLists.txt, I see that CMake's 
> CheckCXXCompilerFlag is included, and CHECK_CXX_COMPILER_FLAG is called with 
> each flag to test.
>
> Looking at CMake's CHECK_CXX_COMPILER_FLAG, I see it tests the compiler's 
> stdout (or stderr?) against these regular expressions:
>
>     # Some compilers do not fail with a bad flag
>     FAIL_REGEX "unrecognized .*option"                     # GNU
>     FAIL_REGEX "unknown .*option"                          # Clang
>     FAIL_REGEX "ignoring unknown option"                   # MSVC
>     FAIL_REGEX "warning D9002"                             # MSVC, any lang
>     FAIL_REGEX "[Uu]nknown option"                         # HP
>     FAIL_REGEX "[Ww]arning: [Oo]ption"                     # SunPro
>     FAIL_REGEX "command option .* is not recognized"       # XL
>     FAIL_REGEX "not supported in this configuration; ignored"       # AIX
>     FAIL_REGEX "File with unknown suffix passed to linker" # PGI
>
> None of these regex tests will catch the Clang warning above.
>
> My first inclination was to see if I could set a Clang flag (like "-Werror") 
> to cause unused arguments to produce an error. But I can't tell how to do 
> that with CMake. If somebody knows how to do this from within the GNU Radio 
> sources, that would be ideal. Instead, I patched CMake as follows:
>
> --- /opt/local/share/cmake-2.8/Modules/CheckCXXCompilerFlag.cmake.orig  
> 2012-05-04 23:41:16.000000000 -0700
> +++ /opt/local/share/cmake-2.8/Modules/CheckCXXCompilerFlag.cmake       
> 2012-05-04 23:43:19.000000000 -0700
> @@ -29,6 +29,7 @@
>      # Some compilers do not fail with a bad flag
>      FAIL_REGEX "unrecognized .*option"                     # GNU
>      FAIL_REGEX "unknown .*option"                          # Clang
> +     FAIL_REGEX "argument unused during compilation"        # Clang
>      FAIL_REGEX "ignoring unknown option"                   # MSVC
>      FAIL_REGEX "warning D9002"                             # MSVC, any lang
>      FAIL_REGEX "[Uu]nknown option"                         # HP
>
> This results in more sensible flag detection for ORC during cmake:
>
>    -- Performing Test have_maltivec
>    -- Performing Test have_maltivec - Failed
>    -- Performing Test have_mfpu_neon
>    -- Performing Test have_mfpu_neon - Failed
>    -- Performing Test have_mfloat_abi_softfp
>    -- Performing Test have_mfloat_abi_softfp - Failed
>    -- Performing Test have_funsafe_math_optimizations
>    -- Performing Test have_funsafe_math_optimizations - Failed
>    ...
>    -- Performing Test have_mpopcnt
>    -- Performing Test have_mpopcnt - Failed
>    ...
>    -- GCC missing xgetbv, Overruled arch avx
>    -- Check size of void*[8]
>    -- Check size of void*[8] - done
>    -- CPU width is 64 bits, Overruled arch 32
>    -- Available architectures: 
> generic;64;3dnow;abm;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2
>    -- Available machines: 
> generic_orc;sse2_64_orc;sse3_64_orc;ssse3_64_orc;sse4_1_64_orc
>
> ...and more importantly, I can compile GNU Radio and run gnuradio-companion.
>
> I see some similar patch history for CMake that suggests my fix is a good one:
>
>    http://public.kitware.com/Bug/view.php?id=12394
>
> I looked at the CMake repository, and it looks like they haven't yet 
> identified or fixed this problem:
>
>    
> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CheckCXXCompilerFlag.cmake;hb=HEAD
>
> So I'll submit a patch to CMake. Of course, until a new CMake is released, 
> MacOS builders will run into this problem. So if anybody familiar with CMake 
> knows a way to fix this from GNU Radio, that would be splendid!
>
>        - Jared

Hi Jared,
Thanks for the information and reporting this. Obviously, this would
be a cmake patch issue, not ours, but hopefully helpful for people
working with GNU Radio in the same environment. Glad to hear you got
things working, though!

Tom