Integrated arm assembler doesn't accept -mfpu=neon as -Wa argument

[nico]

Bugzilla Link	20700
Resolution	FIXED
Resolved on	Jul 27, 2015 18:50
Version	unspecified
OS	All
Blocks	#20796 #22065
CC	@nico,@rengolin

Extended Description

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.

[nico]

assigned to @rengolin

[rengolin]

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?

[nico]

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"

[nico]

Err, pretend that there's a -target arm-linux-androideabi on that command too (it doesn't change anything)

[rengolin]

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.

[rengolin]

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.

[rengolin]

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

[rengolin]

Patches proposed:

• http://reviews.llvm.org/D11147
• http://reviews.llvm.org/D11148

[rengolin]

Fixed in r243352 / r243353

[llvmbot]

mentioned in issue #22065