In D151740#4384719, @Mordante wrote:

In D151740#4384671, @pzheng wrote:

In D151740#4384276, @philnik wrote:

Please don't land libc++ patches until the libc++ group has approved.

Oops, sorry for my ignorance, @philnik... I didn't know this rule existed for libc++ patch reviews. Thank you for educating me.

In general in Phabricator when there are blocking reviewers you should wait on their approval.

In D151740#4384276, @philnik wrote:

Please don't land libc++ patches until the libc++ group has approved.

Add undef after include

Thanks for the fix, @DavidSpickett! I confirm that this patch fixes the crash we encountered.

Thanks for the feedback, @DavidSpickett! Our longjmp implementation does not use br, so this patch is safe for us. Having said that, I do understand your concern over not generating a bti after setjmp when both sls-blr and branch target enforcement are enabled.

Sure, @thakis. We are working with our IT department to get to the bottom of this and will report the issue to the container vendor if IT concludes it's a container bug.

Sure, I'll monitor the buildbot in case this causes any failures.

I just proposed the new workaround in D140233.

Thanks for checking, @haowei!

I did more experiments with the command. Looks like replacing UTC with GMT worked correctly in the container. For example, env TZ=GMT touch -t "197001010000.16". This is functionally equivalent to env TZ=UTC touch -t "197001010000.16" and probably won't break anything. Any concern with this approach?

In D139980#3995615, @haowei wrote:

In D139980#3995526, @pzheng wrote:

Thanks for acting upon this quickly, @thakis!

Sorry for the inconveniences caused by this change, @haowei. Do you mind trying the other form of the command (touch -d "1970-01-01T00:00:16Z") on your builder and see if that works? I am hoping that we can have a simple workaround for the container issue I encountered without breaking any other stuff of course.

I don't have ssh access on builder bots, unfortunately. If you look at the error output, -d flag looks like is not supported at all on Big Sur. In that case, using -d will break LLVM build on all Big Sur or older Mac OS and it would be undesirable.

If this is the only test your container has trouble has. How about using LIT_FILTER_OUT env arg to bypass this test in your container?

Thanks for acting upon this quickly, @thakis!

Thanks for reviewing, @int3!

Thanks for reviewing!

Add a dedicated test

minor update to the commit messasge

Add a test

Update test based on review feedback

Thanks for reviewing!

minor change

Thanks for reviewing the patch, @nickdesaulniers. I have added a test for the change.

Add a test

In D129032#3628870, @thakis wrote:

Looks fine to me.

May I ask what motivates all these changes? Are you trying to build a particular project? Is it difficult to not pass link.exe-only flags to lib.exe in that project for some reason?

Thanks!

Thanks, @thieta! @hans, please let me know if there is anything I need to address.

Thanks!

Ignore the flag

Thanks for the comments, @hans and @thieta! I haven't done any verification of anything built with this flag yet. So, I am not very confident whether there's more to it than what's documented by Microsoft. I guess, for now, we'll just ignore the flag. At some point, I'll probably get a chance to do more testing on this and maybe we can revisit it then.

minor change

Use getAsInteger

Fix a typo

Create a new test

I guess it's a little weird to piggyback the test into nodefaultlib.test. :) Will put it into a new test instead.

Thanks for the feedback, @hans and @thieta. I have added a test case which can trigger the bug.

Add a test case

Small update the test

Update the test to address @mstorsjo's comments.