-Wunused-command-line-argument for assembly files

Clang Frontend
1

Clang utilizes LLVMOption to process command line options. Each option has a “claimed” bit to state whether the option has been processed by APIs like hasArg/getLastArg.

In clangDriver, most action classes utilize clang::driver::tools::Clang. Clang::ConstructJob is where most driver options are handled. Target-specific options are handled by Clang 's member function RenderTargetOptions. For assembler input, we use ClangAs whose ConstructJob method handles very few options.

Therefore, most compilation options will lead to a -Wunused-command-line-argument diagnostic.

On the other hand, for linking, we claim all CompileOnly_Group options, not seeing -Wunused-command-line-argument diagnostics. This is partly because it’s very common to use CFLAGS/CXXFLAGS for linking.

% clang -c -faddrsig -ftime-trace -falign-functions=16 -fpic -march=generic a.s
clang: warning: argument unused during compilation: '-faddrsig' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-ftime-trace' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-falign-functions=16' [-Wunused-command-line-argument]
% clang -c -faddrsig -ftime-trace -falign-functions=16 -fpic -march=generic a.S  # no diagnostic
% clang -faddrsig -ftime-trace -falign-functions=16 -fpic -march=generic a.o  # no diagnostic
% clang -c -faddrsig -ftime-trace -falign-functions=16 -fpic -march=x86-64 a.c  # no diagnostic

What do people think of the diagnostics for input assembly files that do not need preprocessing? Shall we keep -Wunused-command-line-argument or suppress it like we do for linking and assembler-with-cpp? I have mixed feelings.

On one hand, I do see that people may see the diagnostics for assembly files are annoying.
On the other hand, this may push projects to think of ASFLAGS when they do assemble assembly files.

Note: GCC doesn’t have the -Wunused-command-line-argument feature. When assembling a file, it seems to accept every option that a C file accepts.

Appendix

GNU make’s default rules:

COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
COMPILE.S = $(CC) $(ASFLAGS) $(CPPFLAGS) $(TARGET_MACH) -c
COMPILE.s = $(AS) $(ASFLAGS) $(TARGET_MACH)
2

When people try and do that they often end up being too clever for their own good, including a subset of the flags that works for them but then doesn’t work when you come along and port the software to a different ISA/ABI/compiler/etc. IMO you should always assemble with $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH), whether .s or .S, and let the driver figure out what of that is needed for that specific file. Unused argument warnings for things like this have always annoyed me.

1 Like
3

I did some fixes around assembler options for ClangBuiltLinux and that seems like a project that would be helped by these unused argument warnings. Of course the primary build is with GCC, so clearly they do handle its behaviour too.

@nickdesaulniers do you remember any situations where this warning was useful to you? And would those have also been detected by later errors regardless e.g. “instruction requires…”.

4

-Wunused-command-line-argument has helped us make Kbuild (the Linux kernel’s build system) more disciplined, but it is generally a massive PITA since it falls on users of clang to “untangle” cflags from ldflags (for example).

@nickdesaulniers do you remember any situations where this warning was useful to you?

-Wunused-command-line-argument leaves a bad taste in my mouth, because I don’t recall it being //useful//. IIRC every instance was something harmless. When combined with -Werror, -Wunused-command-line-argument basically just breaks the build.

And would those have also been detected by later errors regardless e.g. “instruction requires…”.

I don’t think so, though I might be misremembering.

Either way, I’d appreciate a few tests against the linux kernel before submitting any changes wrt. -Wunused-command-line-argument behavior.