Andy Polyakov

Hmmm... As for -fembed-bitcode. Consider a.c ``` int foo(); int main() { return foo(); } ``` and b.c ``` int foo() { return 42; } ``` `clang -fembed-bitcode -c -O2...

> cc-does-not-add-flto As already mentioned, cargo does **not** convey the information you expect, and there is nothing cc-rs can do about it. In other words it's not a cc-rs problem.

> So, originally, you were saying that the ideal way of performing cross language LTO would be to I'm merely pointing out inconsistencies in rustc -> clang automatic flag mappings....

> > rustc would perform LTO on rust and C code separately, and then link them together > > There is no such thing as performing LTO separately. Linker is...

To summarize. A case has been made for ineffectualness of the current Rust -Clto to clang -flto option mappings. The only arguably meaningful/working mapping is -Clinker-plugin-lto to -flto, which is...

> Won't `-flto` able to optimize within the C/C++ library, even if it cannot be optimized across language boundaries? I don't follow. If you question effectiveness of -flto, then why...

> Did some research, for clang it seems to support this > > llvm-link file1.bc file2.bc file3.bc -o merged.bc > llc merged.bc -filetype=obj -o merged.o I suppose the expectation is...

> Just as a side note, if you want to create LTO objects that contain both bitcode and ELF, the option is `-ffat-lto-objects`, not `-fembed-bitcode`. It doesn't make https://github.com/rust-lang/cc-rs/issues/1463#issuecomment-2854416498 work...

> And of course you need to combine it with a `-flto` option, it's not going to do anything by itself. Ah! -flto alone emits raw bitcode, while in **combination**...

> it would be possible to keep -Clto mappings Just in case, it's still more than appropriate to add -Clinker-plugin-lto mapping.