Differential D120654
WoA: Change target triple & try_compile config Authored by rovka on Feb 28 2022, 3:21 AM.
Details This affects the Windows on Arm builders: We make 2 changes:
the vendor seems to confuse flang-new, so we plug an 'unknown' there.
use the debug configuration for try_compile commands, and fails to find
Diff Detail
Event TimelineComment Actions
Not opposed to the change in itself (although many such MSVC configs use pc as triple, see e.g. https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/GetHostTriple.cmake#L5-L18), but it would be great if someone could have a look and see why things fail without that vendor field, as that sounds like an issue that should be resolved too. Comment Actions I wanna say flang-new is a proper program now not the wrapper script? If so could be something in flang's driver that is missing compared to clang's. Looks good as far as the builds go. Comment Actions Thanks for this patch, @rovka ! This change makes a lot of sense to me. Essentially, it makes the CMake configuration:
Now, there are these confusing failures in Flang, which are most likely related to "effective" triples. Clang allows you to skip the vendor and it probably does that for consistency with GCC (from https://wiki.osdev.org/Target_Triplet):
However, internally Clang uses so-called "effective" triples, which do contain the vendor (here's a Clang test to demonstrate this). As Flang's compiler driver is based on clangDriver (Clang's driver library), it inherits this logic. In many cases, it doesn't matter whether you use: -DLLVM_HOST_TRIPLE=aarch64-windows-msvcor -DLLVM_HOST_TRIPLE=aarch64-pc-windows-msvcbecause (note how the vendor is included in the output): clang -target aarch64-windows-msvc --print-effective-triple aarch64-unknown-windows-msvc19.11.0 The effective triple is what clangDriver will use internally. However, the tests that @rovka is referring to are Flang's frontend driver unit tests. Neither the frontend driver nor the corresponding unit tests in Flang use clangDriver, so aarch64-windows-msvc is used verbatim and windows is parsed as vendor and msvc as OS. And things go "wrong". This is not an issue in Clang, as AFAIK there are no unit tests like this (i.e. most/all code-gen tests are LIT tests that are run via clang). OK, that's a long comment, I hope that it makes sense :) Many thanks to Diana for digging into this with me! Comment Actions I think the issue here, is that LLVM_HOST_TRIPLE is handled inconsistently in the codebase. When a user passes an explicit triple (e.g. via Clang's --target), it usually gets normalized before it's used. The use of LLVM_HOST_TRIPLE and similar is much more inconsistent though; in some cases in the codebase (in some tools), it works fine with a non-normalized triple, but others fail. I think we should move towards always normalizing the triples before they're used like that, even for the compiled-in hardcoded defaults, to make it behave the same as ones passed on the command line. Comment Actions @mstorsjo I think that would be a noble effort :) But even if we did that, it would still make sense for the buildbots to show the "best practice". |