[PATCH] D98023: [clang] Don't default to a specifically shared libunwind on mingw with a g++ driver

Petr Hosek via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Mar 6 14:20:20 PST 2021


phosek added a comment.

In D98023#2609368 <https://reviews.llvm.org/D98023#2609368>, @phosek wrote:

> In D98023#2609328 <https://reviews.llvm.org/D98023#2609328>, @mstorsjo wrote:
>
>> In D98023#2609318 <https://reviews.llvm.org/D98023#2609318>, @phosek wrote:
>>
>>> We see two test failures that appear to have been introduced by this change:
>>
>> Hmm - I'm pretty surprised about that, because the change literally added an `&& !TC.getTriple().isOSCygMing()`, which should evaluate to `&& true` when targeting anything else than mingw/cygwin - and the errors you quoted clearly show a linux triple.
>>
>> I presume you're not actually running the build in a mingw environment, in case that would happen to surprisingly interfere somehow?
>>
>> Feel free to revert - but I'd appreciate if you could try to figure out why it breaks things, as to me, it should be a clear no-op for linux targets.
>
> The only thing that might be somewhat unusual is that we use `CLANG_DEFAULT_RTLIB=compiler-rt`, see https://github.com/llvm/llvm-project/blob/fb2cf0dd609238931b0fc53ef0ea2172a99307ae/clang/cmake/caches/Fuchsia-stage2.cmake#L34

Actually, I don't think it's this commit that broke those tests. It's probably D98022 <https://reviews.llvm.org/D98022>, both of these changes landed around the same time and our bots pick them up in the same batch and I implicitly assumed that this one is more likely since the other one is just fixing a typo, but looking at the failure, it's likely the other one that caused the issue, sorry about the confusion.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98023/new/

https://reviews.llvm.org/D98023



More information about the cfe-commits mailing list