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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
