One nit, LGTM otherwise. Thanks!

@jpaquette, what do you think?

LGTM.

In D124474#3475550, @beanz wrote:

In D124474#3475539, @azharudd wrote:

In this case I'm just trying to make it work with existing build configurations where it is being used (for example Swift). We should definitely be moving away from LLVM_BUILD_EXTERNAL_COMPILER_RT in favor of LLVM_ENABLE_RUNTIMES eventually though.

My point here is that maybe you should move away from the legacy way of building now rather than improving it... Not sure how @phosek feels about this. I would personally very much prefer if we only had one way to build compiler-rt instead of the half dozen we have today.

In D124474#3475432, @beanz wrote:

I question whether we should be extending this or killing it off... Is there a reason you're using LLVM_BUILD_EXTERNAL_COMPILER_RT instead of LLVM_ENABLE_RUNTIMES=compiler-rt?

Thanks Alex! It was not just the MemoryAccessSize test, but the other unit tests were failing too. I disabled those as well in b4b8e1446a2ba1a25488ec5e6e927fa9b54cb4f8.

The newly added unit tests are failing on Darwin. Can you please look into it? Would it possible to revert this until the issue is resolved?

Let me go ahead and mark this test as unsupported on Darwin for now until we get it sorted out.

In D107359#2928008, @dvyukov wrote:

In D107359#2925933, @azharudd wrote:

@dvyukov, this appears to be causing test failure on Darwin. Can you please look into it.

Failed Tests (1):

ThreadSanitizer-x86_64 :: cxa_guard_acquire.cpp

https://green.lab.llvm.org/green/job/clang-stage1-RA/23006/testReport/junit/ThreadSanitizer-x86_64/ThreadSanitizer-x86_64/cxa_guard_acquire_cpp/

Humm... I've looked at this, but so far don't have any concrete ideas.

First, I see that this build also includes these 2 other changes that touched this code:
https://github.com/llvm/llvm-project/commit/0bc626d516a201953ef6a45be0d059d70672d7db
https://github.com/llvm/llvm-project/commit/e3f4c63e78b1ed54f0a35aeb30730e5c74bcfeed
here is build info:
https://green.lab.llvm.org/green/job/clang-stage1-RA/23006/

Also I see this is the only test that failed:
https://green.lab.llvm.org/green/job/clang-stage1-RA/23006/testReport/junit/ThreadSanitizer-x86_64/ThreadSanitizer-x86_64/

But it seems that we don't have any tests for pthread_once, so we can't say if this issue is related to cxa_guard_acquire specifically, or to both cxa_guard_acquire and pthread_once. That may have helped to narrow the problem down.

The only semantic change for __cxa_guard_acquire that I see is that we now test "!thr->in_ignored_lib" before doing Acquire/Release. But I don't see how _not_ calling these functions can cause any crashes...

OnPotentiallyBlockingRegionBegin/End was already present in __cxa_guard_acquire.

So for now I am puzzled...

Azharuddin, can you run this test under gdb and do a "bt", "disass" and "info registers" on SIGSEGV?

And FutexWait is the same sched_yield on mac as we had before in this code.

@dvyukov, this appears to be causing test failure on Darwin. Can you please look into it.

In D104764#2895658, @phosek wrote:

In D104764#2895650, @azharudd wrote:

@phosek, the config where I'm seeing this is a two stage bootstrap build. Could you try building again with the just built clang and see if it still works for you? I seem to be able to reliably reproduce the error locally.

Yes, that's what we use on our bots as well. However, I just noticed that your bots are using ThinLTO, is that correct? We always use full LTO and it's possible that this issue only manifests in ThinLTO.

In D104764#2895638, @phosek wrote:

In D104764#2895621, @azharudd wrote:

Should this apply to Darwin even when not using LLD?

I'm seeing an error which tracks down to this change. It works fine without the -mllvm,-O0 link flags.

FAILED: bin/llvm-tblgen 
[...snip...]
Remaining virtual register operands
UNREACHABLE executed at .../llvm-project/llvm/lib/CodeGen/MachineRegisterInfo.cpp:209!
clang-13: error: unable to execute command: Abort trap: 6
clang-13: error: linker command failed due to signal (use -v to see invocation)

https://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/4221/consoleFull

It should, ld64 supports passing flags to libLTO via the -mllvm flag. We have been using this on our macOS bots for a few weeks and haven't run into any issues (they are using using ld64, not lld).

Should this apply to Darwin even when not using LLD?

In D106155#2887338, @mtrofin wrote:

In D106155#2886634, @DavidSpickett wrote:

The error comes from gtest-port.cc which does #import <Foundation/Foundation.h>. Is it possible there is some C++/Objective C mixing issue here and we need to add some a flag or build option? (though if #import works at all it must have some understanding)

Ah, I see. Can we just disable benchmark testing for iOS?

Created https://reviews.llvm.org/D106281 - I don't have a iOS build setup, though, so it'd be good if someone verified this; or we can wait for it to land?

This is failing for arm64 with iPhoneOS SDK.

This won't work on Darwin.

Could we revert this until we have a fix for the errors showing up on Darwin?

In D85773#2211929, @dberris wrote:

LGTM from me if XRay actually does work on non-x86_64 macOS.

Merged in f36909d9. Thanks!

In D85554#2231462, @dokyungs wrote:

In D85554#2230791, @azharudd wrote:

Reverted this in 8831e34771fec4dfbe62a6e31d9bc9419a3b93c3 to get the bots green again. Please feel free to ping if you need someone to test this on macOS.

Could you try this patch again on top of https://reviews.llvm.org/D86247 which hopefully fixes the failing test on macOS?

@dokyungs, looking into this now.

Reverted this in 8831e34771fec4dfbe62a6e31d9bc9419a3b93c3 to get the bots green again. Please feel free to ping if you need someone to test this on macOS.

In D85554#2227180, @dokyungs wrote:

In D85554#2226648, @azharudd wrote:

Looks like this change is causing the value-profile-load.test test to fail. Can you please take a look?

******************** TEST 'libFuzzer :: value-profile-load.test' FAILED ********************
Script:
--
: 'RUN: at line 2';     /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/./bin/clang  --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/lib/fuzzer -arch x86_64 -stdlib=libc++ -mmacosx-version-min=10.9 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk /Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/test/fuzzer/LoadTest.cpp -fsanitize-coverage=trace-gep -o /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/tools/clang/runtime/compiler-rt-bins/test/fuzzer/X86_64DefaultDarwinConfig/Output/value-profile-load.test.tmp-LoadTest
: 'RUN: at line 3';   not  /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/tools/clang/runtime/compiler-rt-bins/test/fuzzer/X86_64DefaultDarwinConfig/Output/value-profile-load.test.tmp-LoadTest -seed=2 -use_cmp=0 -use_value_profile=1 -runs=20000000 2>&1 | FileCheck /Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/test/fuzzer/value-profile-load.test
--
Exit Code: 1

Command Output (stderr):
--
+ : 'RUN: at line 2'
+ /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/./bin/clang --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/lib/fuzzer -arch x86_64 -stdlib=libc++ -mmacosx-version-min=10.9 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk /Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/test/fuzzer/LoadTest.cpp -fsanitize-coverage=trace-gep -o /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/tools/clang/runtime/compiler-rt-bins/test/fuzzer/X86_64DefaultDarwinConfig/Output/value-profile-load.test.tmp-LoadTest
+ : 'RUN: at line 3'
+ not /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/tools/clang/runtime/compiler-rt-bins/test/fuzzer/X86_64DefaultDarwinConfig/Output/value-profile-load.test.tmp-LoadTest -seed=2 -use_cmp=0 -use_value_profile=1 -runs=20000000
+ FileCheck /Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/test/fuzzer/value-profile-load.test
/Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/test/fuzzer/value-profile-load.test:1:8: error: CHECK: expected string not found in input
CHECK: AddressSanitizer: global-buffer-overflow
       ^
<stdin>:1:1: note: scanning from here
INFO: Seed: 2
^
<stdin>:5:27: note: possible intended match here
INFO: A corpus is not provided, starting from an empty corpus
                          ^

Input file: <stdin>
Check file: /Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/test/fuzzer/value-profile-load.test

-dump-input=help explains the following input dump.

Input was:
<<<<<<
           1: INFO: Seed: 2
check:1'0     X~~~~~~~~~~~~ error: no match found
           2: INFO: Loaded 1 modules (3 inline 8-bit counters): 3 [0x10af2bac8, 0x10af2bacb), 
check:1'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           3: INFO: Loaded 1 PC tables (3 PCs): 3 [0x10af2bad0,0x10af2bb00), 
check:1'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           4: INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
check:1'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           5: INFO: A corpus is not provided, starting from an empty corpus
check:1'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:1'1                               ?                                   possible intended match
           6: #2 INITED cov: 2 ft: 4 corp: 1/1b exec/s: 0 rss: 31Mb
check:1'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           7: #14 NEW cov: 2 ft: 5 corp: 2/4b lim: 4 exec/s: 0 rss: 31Mb L: 3/3 MS: 2 CrossOver-CopyPart-
check:1'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           8: #242 NEW cov: 2 ft: 6 corp: 3/9b lim: 6 exec/s: 0 rss: 31Mb L: 5/5 MS: 3 ShuffleBytes-ShuffleBytes-CopyPart-
check:1'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           9: #477 NEW cov: 3 ft: 11 corp: 4/17b lim: 8 exec/s: 0 rss: 31Mb L: 8/8 MS: 5 EraseBytes-ChangeByte-EraseBytes-InsertRepeatedBytes-CopyPart-
check:1'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          10: #480 NEW cov: 3 ft: 13 corp: 5/24b lim: 8 exec/s: 0 rss: 31Mb L: 7/8 MS: 3 ChangeByte-InsertByte-CopyPart-
check:1'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           .
           .
           .
>>>>>>

--

********************

Could you please apply the following patch and see if it fixes the regression?

https://reviews.llvm.org/D86247

Looks like this change is causing the value-profile-load.test test to fail. Can you please take a look?

******************** TEST 'libFuzzer :: value-profile-load.test' FAILED ********************
Script:
--
: 'RUN: at line 2';     /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/./bin/clang  --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/lib/fuzzer -arch x86_64 -stdlib=libc++ -mmacosx-version-min=10.9 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk /Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/test/fuzzer/LoadTest.cpp -fsanitize-coverage=trace-gep -o /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/tools/clang/runtime/compiler-rt-bins/test/fuzzer/X86_64DefaultDarwinConfig/Output/value-profile-load.test.tmp-LoadTest
: 'RUN: at line 3';   not  /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/tools/clang/runtime/compiler-rt-bins/test/fuzzer/X86_64DefaultDarwinConfig/Output/value-profile-load.test.tmp-LoadTest -seed=2 -use_cmp=0 -use_value_profile=1 -runs=20000000 2>&1 | FileCheck /Users/buildslave/jenkins/workspace/clang-stage1-RA/llvm-project/compiler-rt/test/fuzzer/value-profile-load.test
--
Exit Code: 1

Hey Eli,

In D84700#2178300, @jhenderson wrote:

No issues from my point of view, aside from the suggested comment change.

Since it is just a change in the directory name, I think this would still work fine on other platforms.

Looks like the test added here is failing on Darwin. Can you please look into it.

Looks like this is failing on Darwin: