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

[Jared Boone]

On May 8, 2012, at 2:29 PM, Josh Blum wrote:

>> 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"
>> 
> OK so, thats a pretty thorough analysis of the issue. I guess there
> there is question of how to fix/who to blame:
> 
> 1) cmake is at fault, and that patch needs to be in there

The CMake team has already incorporated a patch against forthcoming CMake 2.8.9:

http://public.kitware.com/Bug/view.php?id=13194

However, I don't think the patch is ideal -- regex on compiler output seems 
like running with scissors to me. It'd be better for Clang to report an error 
by shell return code. But see below, because I don't think CMake has an 
alternative to output string parsing, at the moment.

> 2) clang is at fault and should error/not warn.

This is what I believe, but in the short term, it appears the CMake people have 
already had to deal with warnings that are errors as far as CMake is concerned.

> Is there a clang flag to force unknown flags to become errors?
> I think you can just pass another flag to CHECK_CXX_COMPILER_FLAG along
> with the one being check.

I tried using clang -Werror, but that does not change the return code -- it's 
"0" with or without -Werror. I noodled around with 
-fdiagnostics-show-category=id and -fdiagnostics-show-category=name, but didn't 
get any reaction from Clang. I even dug through the Clang source and tried to 
target the specific warning by name, like this:

/usr/bin/c++ -Werror=unused-command-line-argument -Dhave_maltivec -maltivec -o 
test.cxx.o -c test.cxx

Still, I get "0".

It looks like the Clang team is aware of and has addressed this problem in time 
for the forthcoming LLVM 3.1 release:

http://llvm.org/bugs/show_bug.cgi?id=12181

> And if thats not possible we could switch to CHECK_CXX_SOURCE_COMPILES
> to help with the flag tests.
> 
> 3) volk has a way to specify compiler specific flags. But its probably
> wrong to use this if clang is using GCC flags and reporting as GNU.
> http://gnuradio.org/cgit/gnuradio.git/tree/volk/gen/archs.xml


Unless there's a workable Clang flag scheme I haven't tried, I'm not sure this 
would address the problem for LLVM releases < 3.1, due to what I described 
above re: return codes.

Perhaps attempting to compile a single inline assembly instruction for the 
architecture/instruction set in question would yield a proper failure, 
regardless of Clang's behavior?

        - Jared