This is an archive of the discontinued LLVM Phabricator instance.

[clang][driver] Add -ansi option to CompileOnly group
ClosedPublic

Authored by tbaeder on Dec 15 2020, 11:52 PM.

Details

Summary

-ansi is documented as being the "same as -std=c89", but there are differences when passing it to a link:

clang -c test.c -o test.o

clang test.o -o test -std=c89   # Works, no problem

clang test.o -o test -ansi  # Warning about unused -ansi option

-std= is claimed in this case in clang/lib/Driver/Driver.cpp at the end of handleArguments() via Args.ClaimAllArgs(options::OPT_CompileOnly_Group). This does not include -ansi right now however, since it does not belong to the CompileOnly group.

Adding -ansi to said group makes sense since it's supposed to be an alias for -std=c89 and resolves this inconsistency.

Diff Detail

Event Timeline

tbaeder requested review of this revision.Dec 15 2020, 11:52 PM
tbaeder created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptDec 15 2020, 11:52 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
tbaeder updated this revision to Diff 313872.Dec 28 2020, 10:34 AM
tbaeder added reviewers: jansvoboda11, thakis, Bigcheese.

Rebased on lastest main branch and added a few more reviewers from git blame'ing the Options.td file

This seems reasonable to me, but I wonder if there's a way we can add test coverage for the change?

I guess I could add a test for the example I posted, but I'm not sure of how much value that is. Or do you mean a test case that -ansi and -std=c89 behave the same in every situation?

I guess I could add a test for the example I posted, but I'm not sure of how much value that is. Or do you mean a test case that -ansi and -std=c89 behave the same in every situation?

I was thinking of a test that demonstrates that a given flag isn't passed along to the linker so that we could test that neither -std=whatever nor -ansi get passed along (to ensure we don't regress accidentally in the future). However, I'm not certain if that's a big ask or not.

That sounds good but it's different to what this patch is trying to accomplish, isn't it? -ansi already doesn't get passed to the linker.
E.g. with clang 10.0.1 without this patch:

~ ❯ clang test.o -o test -ansi -###
clang version 10.0.1 (Fedora 10.0.1-3.fc32)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang-10: warning: argument unused during compilation: '-ansi' [-Wunused-command-line-argument]
 "/usr/bin/ld" "--hash-style=gnu" "--build-id" "--eh-frame-hdr" "-m" "elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" "test" "/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crt1.o" "/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crti.o" "/usr/bin/../lib/gcc/x86_64-redhat-linux/10/crtbegin.o" "-L/usr/bin/../lib/gcc/x86_64-redhat-linux/10" "-L/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64" "-L/usr/bin/../lib64" "-L/lib/../lib64" "-L/usr/lib/../lib64" "-L/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../.." "-L/usr/bin/../lib" "-L/lib" "-L/usr/lib" "test.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/bin/../lib/gcc/x86_64-redhat-linux/10/crtend.o" "/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crtn.o"

That sounds good but it's different to what this patch is trying to accomplish, isn't it? -ansi already doesn't get passed to the linker.
E.g. with clang 10.0.1 without this patch:

~ ❯ clang test.o -o test -ansi -###
clang version 10.0.1 (Fedora 10.0.1-3.fc32)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang-10: warning: argument unused during compilation: '-ansi' [-Wunused-command-line-argument]
 "/usr/bin/ld" "--hash-style=gnu" "--build-id" "--eh-frame-hdr" "-m" "elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" "test" "/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crt1.o" "/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crti.o" "/usr/bin/../lib/gcc/x86_64-redhat-linux/10/crtbegin.o" "-L/usr/bin/../lib/gcc/x86_64-redhat-linux/10" "-L/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64" "-L/usr/bin/../lib64" "-L/lib/../lib64" "-L/usr/lib/../lib64" "-L/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../.." "-L/usr/bin/../lib" "-L/lib" "-L/usr/lib" "test.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/bin/../lib/gcc/x86_64-redhat-linux/10/crtend.o" "/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crtn.o"

Hmm, I think I misunderstood what you had originally written then with:

-ansi is documented as being the "same as -std=c89", but there are differences when passing it to a link:

Regardless, the request is whether we can add test coverage to ensure we don't regress this behavior in the future.

tbaeder updated this revision to Diff 316115.Jan 12 2021, 9:06 AM

Okay, I've added a test and made sure it fails before and succeeds after this patch.

tbaeder updated this revision to Diff 316118.Jan 12 2021, 9:14 AM
aaron.ballman accepted this revision.Jan 12 2021, 9:50 AM

LGTM, thank you for this!

This revision is now accepted and ready to land.Jan 12 2021, 9:50 AM

And thank you for reviewing my patches :)

And thank you for reviewing my patches :)

Happy to help! Btw, do you need someone to commit them on your behalf?

Yes, I was gonna ask somebody else but if you have time, committing this one and https://reviews.llvm.org/D94478 would be nice

I've commit on your behalf in 348471575d9c24bbfb124ca5eac1589de075da88, thank you for the patch!

Thanks for the commits, Aaron. If you don't mind I have a short question: both commits don't seem to list the test cases, have they not been committed at all or are they filtered out in github and/or phabricator? Did I mess something up?