Consider that you're trying to detect neon support at runtime, and use neon code if the processor supports it. One approach to go about this (used by libvpx, used in chromium) is to build your c files without -mfpu=neon, and have neon assembly in .S files (and the c files then call the .S files). The .S files don't have ".fpu neon" instructions for various reasons (one of them being that clang didn't support .fpu neon until 2 days ago). The build system doesn't make it easy to only pass flags .S files. So one approach would be to pass -Wa,-mfpu=neon. Then all c files are built without neon instructions, but the neon code in the .S files assemble fine. That works fine with gnu as, but the integrated assembler doesn't understand -mfpu=neon as -Wa flag.
Hi Nico, Clang is not very good at passing -Wa flags down at the moment. Is this a Clang error or an assembler error? Can you paste the "clang -v" output?
Sure, but it's easy to try yourself too: thakis@yearofthelinuxdesktop:~/src/chrome/src$ third_party/llvm-build/Release+Asserts/bin/clang -Wa,-masm=fpu -v test.S clang version 3.5.0 (trunk 214024) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.6.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.3 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 clang: error: unsupported argument '-masm=fpu' to option 'Wa,' thakis@yearofthelinuxdesktop:~/src/chrome/src$ third_party/llvm-build/Release+Asserts/bin/clang -Wa,-masm=fpu -v test.S -### clang version 3.5.0 (trunk 214024) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.6.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.3 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 clang: error: unsupported argument '-masm=fpu' to option 'Wa,' "/usr/local/google/home/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-E" "-disable-free" "-main-file-name" "test.S" "-mrelocation-model" "static" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-target-linker-version" "2.22" "-v" "-dwarf-column-info" "-resource-dir" "/usr/local/google/home/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.5.0" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/usr/local/google/home/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.5.0/include" "-internal-externc-isystem" "/usr/include/x86_64-linux-gnu" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir" "/usr/local/google/home/thakis/src/chrome/src" "-ferror-limit" "19" "-fmessage-length" "121" "-mstackrealign" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "/tmp/test-01b1ce.s" "-x" "assembler-with-cpp" "test.S" "/usr/local/google/home/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang" "-cc1as" "-triple" "x86_64-unknown-linux-gnu" "-filetype" "obj" "-main-file-name" "test.S" "-target-cpu" "x86-64" "-fdebug-compilation-dir" "/usr/local/google/home/thakis/src/chrome/src" "-dwarf-debug-producer" "clang version 3.5.0 (trunk 214024)" "-o" "/tmp/test-bede9c.o" "/tmp/test-01b1ce.s" "/usr/bin/ld" "-z" "relro" "--hash-style=gnu" "--build-id" "--eh-frame-hdr" "-m" "elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" "a.out" "/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o" "/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crti.o" "/usr/lib/gcc/x86_64-linux-gnu/4.6/crtbegin.o" "-L/usr/lib/gcc/x86_64-linux-gnu/4.6" "-L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu" "-L/lib/x86_64-linux-gnu" "-L/lib/../lib64" "-L/usr/lib/x86_64-linux-gnu" "-L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.." "-L/usr/local/google/home/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/../lib" "-L/lib" "-L/usr/lib" "/tmp/test-bede9c.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/gcc/x86_64-linux-gnu/4.6/crtend.o" "/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crtn.o"
Err, pretend that there's a `-target arm-linux-androideabi` on that command too (it doesn't change anything)
Doesn't matter the target, this is a Clang issue when dealing with -Wa flags. I could keep adding flags to -Wa but we need some planning first, as so far, not much is actually accepted in there. We need to consult the Clang experts.
Nico, I'm adding the following Wa flags to be passed directly to the target: -mcpu -mfpu -march -mfloat-abi as they are the most common assembler flags I know (and that the kernel also uses). However, I don't know what the -masm you mention does, and GCC/GAS doesn't seem to recognise it either. Is this related to Microsoft Asm? If so, I shall not do that one now, and another bug shall be created.
Hi Nico, I'm back looking at those bugs. Did you work around this one by adding ".fpu neon" to the ASM files, or is this still holding Chromium builds? If the latter, I'd recommend you to work around, so we can fix this one properly after the other, more complicated, fixes. If the former, then we need to mark this as not blocking the Chromium bug and close that, since this is the last issue. cheers, --renato
Patches proposed: - http://reviews.llvm.org/D11147 - http://reviews.llvm.org/D11148
Fixed in r243352 / r243353