This is an archive of the discontinued LLVM Phabricator instance.

[Driver,ARM,AArch64] Ignore -mbranch-protection= diagnostics for assembler input
AbandonedPublic

Authored by MaskRay on Aug 23 2023, 6:15 PM.

Details

Summary

Some options are only claimed in AddARMTargetArgs/AddAArch64TargetArgs/etc (called by
Clang::RenderTargetOptions).
For assembler input, Add*TargetArgs is not called. If an option is
unclaimed, it either leads to a -Wunused-command-line-argument warning
or an error (if TargetSpecific is set)

// clang '-###' --target=aarch64 -mbranch-protection=bti -c a.s
clang: error: unsupported option '-mbranch-protection=' for target 'aarch64'

It seems that ignoring the diagnostics is most useful as it matches GCC
and users can do

clang --target=aarch64 -mbranch-protection=bti -S a.c
clang --target=aarch64 -mbranch-protection=bti -c a.s

without changing the options.

Planned for main and release/17.x

Diff Detail

Event Timeline

MaskRay created this revision.Aug 23 2023, 6:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2023, 6:15 PM
MaskRay requested review of this revision.Aug 23 2023, 6:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2023, 6:15 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Ping:) This is probably a good candidate for release/17.x backporting.

stuij added a comment.Aug 29 2023, 3:15 AM

LGTM. Thanks!

simon_tatham accepted this revision.Aug 29 2023, 3:17 AM

The change LGTM, and "agree with gcc" seems like a reasonable justification in this case.

But I'm curious more generally about what options should / shouldn't be covered by -Wunused-command-line-argument. Doesn't the same reasoning apply to most options that C compilation uses and assembly doesn't? If you have a command of the form clang -someoption -c foo.c, it's surely always convenient for a user to be able to change the .c into a .s, or to put a variable list of files on the end of the command line which might or might not include any .c files. Why is this option in particular different from others? Is there a documented policy anywhere?

This revision is now accepted and ready to land.Aug 29 2023, 3:17 AM

The change LGTM, and "agree with gcc" seems like a reasonable justification in this case.

Thank you both!

But I'm curious more generally about what options should / shouldn't be covered by -Wunused-command-line-argument. Doesn't the same reasoning apply to most options that C compilation uses and assembly doesn't? If you have a command of the form clang -someoption -c foo.c, it's surely always convenient for a user to be able to change the .c into a .s, or to put a variable list of files on the end of the command line which might or might not include any .c files.

-Wunused-command-line-argument does fire for most options when the only input kind is assembly without preprocessing.
It seems that the diagnostics are for assembler input, not assembler-with-cpp...

Why is this option in particular different from others? Is there a documented policy anywhere?

I am not aware of a documented policy anywhere, but I have some notes on https://maskray.me/blog/2023-08-25-clang-wunused-command-line-argument#assembler-input .

Let me ask on Discourse: https://discourse.llvm.org/t/wunused-command-line-argument-for-assembly-files/73111

The change LGTM, and "agree with gcc" seems like a reasonable justification in this case.

Thank you both!

But I'm curious more generally about what options should / shouldn't be covered by -Wunused-command-line-argument. Doesn't the same reasoning apply to most options that C compilation uses and assembly doesn't? If you have a command of the form clang -someoption -c foo.c, it's surely always convenient for a user to be able to change the .c into a .s, or to put a variable list of files on the end of the command line which might or might not include any .c files.

-Wunused-command-line-argument does fire for most options when the only input kind is assembly without preprocessing.
It seems that the diagnostics are for assembler input, not assembler-with-cpp...

Why is this option in particular different from others? Is there a documented policy anywhere?

I am not aware of a documented policy anywhere, but I have some notes on https://maskray.me/blog/2023-08-25-clang-wunused-command-line-argument#assembler-input .

Let me ask on Discourse: https://discourse.llvm.org/t/wunused-command-line-argument-for-assembly-files/73111

I think we should do D159173 .. The warnings are still useful, but we can do it in Driver.cpp to avoid the ForAS hacks.

MaskRay abandoned this revision.Aug 31 2023, 11:27 PM

Obsoleted by D159173.