[compiler-rt] [compiler-rt] [test] Fix using toolchains that rely on Clang default configs (PR #113491)

[Martin Storsjö via llvm-commits]

mstorsjo wrote:

> First, thanks, and I'm sorry for the breakage. I should've thought of this.

No problem - Clang config files can be used in a multitude of ways.

Btw, in a closely related matter, I'm aware of (at least) one other case where Clang users want to specify `--no-default-config` (which I think may be related to Gentoo default configs): Wine can use any Clang installation as cross compiler for windows targets - they don't need any runtime libs or such (they provide all that themselves), they just need a plain Clang executable. But if that Clang is set up with host environment specific defaults, those defaults may conflict with their use of Clang as a cross compiler for another entirely different target. Therefore, Wine also tries to add `--no-default-config` when using Clang in this role (and we're trying to resolve this same issue there as well, that the config file actually may be essential).

To reduce the need for that, if applicable, you could consider switching from a blanket general config file (like `clang.cfg` or what it may be called) to a target specific config file (like `x86_64-unknown-linux-gnu.cfg`), so that it only applies when actually compiling for the intended host, but not if the user specifies any other `-target` option.

> Second, looks good to me, but I'm also happy to `-U_FORTIFY_SOURCE` and such instead if someone really dislikes this approach.

Thanks for the input. Yeah I'm not entirely sure which way forward is better - we can try to land this and see if it works, and if it seems to require more complex workarounds elsewhere, perhaps we can reconsider other approaches.

https://github.com/llvm/llvm-project/pull/113491