We're hitting an assert after this change:

We saw a new warning in Chromium after this, and I wasn't sure if that's intentional:

I just noticed this also broke some lit tests on mac: https://bugs.chromium.org/p/chromium/issues/detail?id=1485487#c0
That's also visible on greendragon: https://green.lab.llvm.org/green/view/Clang/job/clang-stage1-RA/35721/testReport/

In D138846#4649147, @alanphipps wrote:

In D138846#4649110, @akhuang wrote:

I'm still working on a repro, but after this patch we're seeing "truncated profile data" errors in chromium (crbug.com/1485303)

Thank you for the heads-up! If there's an issue, I'm eager to ensure it is addressed. Your repro will be helpful.

Sent my diff along with tests based on Louis's patch as a pull request here: https://github.com/llvm/llvm-project/pull/65961

In D152495#4628887, @aaron.ballman wrote:

That might not be a bad idea in this case -- perhaps -Wunused-condition-variable and group it under -Wunused-variable?

In D152495#4628785, @cor3ntin wrote:

It is used, but only in an assert. Seems like the right fix!

Add release note.

In D153156#4607655, @aaron.ballman wrote:

I agree this should be reverted from 17.x so we have more time to consider an appropriate path forward. Supporting evidence that this will likely be disruptive: https://sourcegraph.com/search?q=context:global+%5E%28%22%5B%5E%22%5D%2B%22PRI.*%29%24+lang:C%2B%2B+-file:.*test.*&patternType=regexp&case=yes&sm=0&groupBy=repo

Given the concerns raised (the PRIuS one in https://godbolt.org/z/v3boc9E6T seems like a good example), and that the fix in D158372 doesn't seem straight-forward, could this be reverted to unbreak things until a revised version is ready?

Maybe add a short release note.

Thanks! I agree. d9ad0681fad9a98f43d9baddb95d505b37153c48 (2013) renamed warn_drv_overriding_t_option to warn_drv_overriding_flag_option.
Perhaps the original name warn_drv_overriding_t_option should be restored.

In D155713#4592667, @rnk wrote:

That doesn't handle the second of your test cases though, where dllimport is put on the member directly:
...
It's not clear to me how we'd want to handle that. I don't think it comes up in libc++, and I can't think of any code that would want to do that either, really.

I think this does actually matter for libc++, I think I have seen this pattern:

template <typename T>
struct Foo {
  _LIBCPP_FUNC_VIS _LIBCPP_EXCLUDE_FROM_ABI void method() { }
};

I can't find an instance right now, though. I think it comes up when you want to have a default visibility function, and also keep it out of the libc++ DSO interface.

In D157602#4580154, @thakis wrote:

@hans Hmm, I wonder if it's related to /Zc:dllexportInlines- (ref https://blog.llvm.org/2018/11/30-faster-windows-builds-with-clang-cl_14.html).

Apologies for the delay, I'm still catching up with my post-vacation backlog.

Since reverting seems non-trivial, I added a triple in https://github.com/llvm/llvm-project/commit/7a1735cd05c2bc0c336f122f01fb35de66e85e16 which I believe should fix the test.

In D157334#4573902, @aaron.ballman wrote:

I'm curious to hear what others think about this (especially @rnk and @hans).

Maybe we want this for the release/17.x branch too?

For those following along, this was relanded in https://reviews.llvm.org/D154007

Confirmed that Chromium's toolchain build works with this.

lgtm

I wasn't sure if you were planning to update the patch to not move the str(const _SAlloc& __sa) const template, but either way is fine by me really.

lgtm

In D155180#4497048, @pfusik wrote:

I think https://reviews.llvm.org/D155185 addresses it better: there are two overloads to handle for now, there will be eight.

Nice!

By the way, do we have a github issue tracking the whole https://discourse.llvm.org/t/improve-autolinking-of-compiler-rt-and-libc-on-windows-with-lld-link/71392/ situation? If so it would be nice to reference it in the commit.

lgtm

Seems handy to me. We could also add this kind of info to the /verbose output, but having a separate option is probably more convenient.

In D154295#4482818, @HaohaiWen wrote:

In D154295#4477203, @hans wrote:

In D154295#4477165, @HaohaiWen wrote:

It would be nice to have some documentation for this feature though.

This feature is same as Linux -gsplit-dwarf.

Right, but it would be nice to document that clang-cl supports it (which is not obvious since it's mostly trying to be cl.exe compatible).

Do you know which doc file should be updated? I haven't found a doc describe -gdwarf for Windows.

In D154286#4485940, @Mordante wrote:

@hans can you test whether this solves the chromium issue with vector. I suspect it doesn't but it would be good to get it confirmed.

In D154295#4477165, @HaohaiWen wrote:

It would be nice to have some documentation for this feature though.

This feature is same as Linux -gsplit-dwarf.

Looks reasonable to me too.

lgtm

Somehow this seems to have made it worse on the bot: https://green.lab.llvm.org/green/view/Clang/job/clang-stage1-RA/34927/

In D154417#4471141, @alexfh wrote:

Given the comment in https://reviews.llvm.org/D153672#4468348, I think, this should be fine to submit.

@hans These are some removals, this might help a tiny bit with D149543. I try to look at the core issue this weekend.

In D150802#4466226, @Mordante wrote:

In D150802#4455204, @hans wrote:

In D150802#4453136, @Mordante wrote:

Does that mean the flag in __config is not set correctly? It was recently updated in D134912.

It's tricky. As discussed on that change, Clang does support 128-bit operations also on Windows so the flag is correct in that sense, but it requires linking with the builtins library which we don't do (yet).

I see. Is there an estimate how long it takes to get the linking with the builtins library will take. I wonder whether we should ship libc++17 with 128 bit support on Windows when it may lead to link time error.

In D149543#4456497, @Mordante wrote:

Interesting. Am I right to assume most of the new size is due to including <string>?

In Chromium we noticed that this almost doubled the preprocessed size of <vector>, from ca 1.6 MB to 3.2 MB. Since it's a widely included header, that results in ca 8 GB (2.5%) of extra code to compile during a full build.

In D152208#4453925, @philnik wrote:

I'm working on adding a CFI run to our CI right now. It looks like I just have to add _LIBCPP_NO_CFI to __make_uninitialized_buffer, given that get_temporary_buffer also has that attribute. I hope to get the patch completed by tomorrow.

It seems Leonard is out at the moment, so I'll go ahead and commit this on his behalf.

In D150802#4453136, @Mordante wrote:

Does that mean the flag in __config is not set correctly? It was recently updated in D134912.

In D152208#4448532, @hans wrote:

We're hitting CFI errors in Chromium after this, see https://github.com/llvm/llvm-project/issues/63523

Looks reasonable to me too.

Sharing in case anyone else runs into the same problem: This caused Chromium builds to fail on Windows due to not linking against compiler-rt's builtins library. It turns out this patch caused us to compile some code doing 128-bit arithmetic and calling the __udivti3 runtime function. We worked around it by defining _LIBCPP_HAS_NO_INT128 until we can make the builtins library part of all our builds.

I noticed that at least for some cases of -Wformat, the line numbers on the left seem to be off: https://github.com/llvm/llvm-project/issues/63524

We're hitting CFI errors in Chromium after this, see https://github.com/llvm/llvm-project/issues/63523

We're seeing assertion failures in Chromium too. Reproducer for x86_64 Linux here: https://bugs.chromium.org/p/chromium/issues/detail?id=1456288#c2

lgtm

-H is supposed to skip outputting headers from -include command line
arguments, but -fshow-skipped-includes was outputting any skipped
includes encountered via -include.