sepavloff added a comment. In D134337#3813798 <https://reviews.llvm.org/D134337#3813798>, @mgorny wrote:
> In D134337#3813779 <https://reviews.llvm.org/D134337#3813779>, @sepavloff > wrote: > >> First clang tries to find `x86_64-pc-linux-gnu-clang.cfg`. Just tool name >> with added suffix `cfg`. No target override, no attempt to split tool name >> into components. It provides possibility to have a separate configuration >> for any tool. The existing mechanism does not search for such file, so >> compatibility cannot be broken. This variant makes it possible to use >> configuration file even if tool name is arbitrary and does not follow usual >> pattern. > > That's incorrect. The existing algorithm uses precisely this file if that's > how clang is named: I was wrong, the target prefix reported by `ToolChain::getTargetAndModeFromProgramName` is everything but the driver component, so indeed the first file tried for configuration is `x86_64-pc-linux-gnu-clang.cfg`. So the new algorithm would try files tried by current implementation and risk of breaking compatibility would be minimized. In D134337#3805368 <https://reviews.llvm.org/D134337#3805368>, @mgorny wrote: > For target, it will try: > > 1. `i386.cfg` (effective triple) > 2. `i386-pc-linux-gnu.cfg` ("fixed" prefix) > 3. `x86_64-pc-linux-gnu.cfg` (orig. prefix) Does it mean that `i386.cfg` would be tried before `i386-pc-linux-gnu.cfg`? It looks more natural to try specific variant first then generic. File `x86_64.cfg` is not used in this algorithm, what is the reason for this? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134337/new/ https://reviews.llvm.org/D134337 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
