Constrain -Clto and -Cembed-bitcode flag inheritance to be clang-only

[jieyouxu]

In rust-lang/rust#136338 we noticed two unsupported inherited flag warnings when the underlying cc is gcc and not clang:

warning: rustc_llvm@0.0.0: Inherited flag "-flto=thin" is not supported by the currently used CC
warning: rustc_llvm@0.0.0: Inherited flag "-fembed-bitcode=all" is not supported by the currently used CC

This PR constraints -Clto and -Cembed-bitcode flag inheritance to be clang-only, compared the current behavior of inheriting the flags for both clang and gcc.

Constrain -Cembed-bitcode flag inheritance to be clang-only

embed-bitcode refers to embedding LLVM bitcode, which is not a thing for gcc¹.

This PR moves the -Cembed-bitcode flag inheritance from being shared by gcc/clang to be clang-only.

Constrain -Clto flag inheritance to be clang-only

While clang supports -flto={thin,fat}, gcc does not support this form. Furthermore, there isn't really a 1-to-1 mapping between clang's ThinLTO/FatLTO and gcc's LTO.

We noticed this in rust-lang/rust#136338 when trying to compile rustc_llvm but with the underlying cc being gcc:

warning: rustc_llvm@0.0.0: Inherited flag "-flto=thin" is not supported by the currently used CC

For instance, gcc has multiple LTO-related / LTO-affecting flags:

• -ffat-lto-objects and -fno-fat-lto-objects. And its docs state:

  -fno-fat-lto-objects improves compilation time over plain LTO, but requires the complete toolchain to be aware of LTO.

• -fwhole-program
• -flto-partition
• -flto-compression-level
• ... and a few more.

This PR moves the -Clto flag inheritance from being shared by gcc/clang to be clang-only.

Footnotes

1. I suppose if you squint super super hard, embedding GIMPLE bytecode somehow...? ↩

[madsmtm]

Looks good to me!

Similar in spirit to #1363, CC @mrkajetanp, why were these originally marked enabled on GCC too? Are there other options here that we are not considering that we should be?

[madsmtm]

I'm gonna merge this immediately, because this PR is clearly correct. I'll look into the other options myself, and file a follow-up PR if needed.

[jieyouxu]

I'm gonna merge this immediately, because this PR is clearly correct. I'll look into the other options myself, and file a follow-up PR if needed.

There may also be cases that while a specific flag-form is supported for both clang and gcc, their exact semantics/behavior do not mirror each other (this is the case of value-less flag-value-form -flto, which is supported by both clang and gcc but they do not mean nearly the same thing AFAIK). However, I haven't looked into that, just a remark.

[madsmtm]

Filed #1380. And yes, you're correct, they may not have the same semantics.

[mrkajetanp]

As originally written, clang and gcc flags were just all one group because if either of the compilers didn't support one you'd just get this warning but it wouldn't be an actual error. Somewhat useful for when someone was using a different compiler than they intended etc.
Now that it's been changed to be more granular it does make sense to move some of these to clang-only, I agree :)