[modules] -print-file-name=libc++.modules.json does not work in mac m1 #109895

ChuanqiXu9 · 2024-09-25T02:34:21Z

I received a private report that -print-file-name=libc++.modules.json doesn't work well in mac m1. Maybe this is related to the installation path of libc++ in MacOS.

Verify needed.

The text was updated successfully, but these errors were encountered:

llvmbot · 2024-09-25T02:34:43Z

@llvm/issue-subscribers-clang-modules

Author: Chuanqi Xu (ChuanqiXu9)

I received a private report that `-print-file-name=libc++.modules.json` doesn't work well in mac. Maybe this is related to the installation path of libc++ in MacOS.

Verify needed.

ChuanqiXu9 · 2024-09-25T05:32:55Z

Also it looks like -print-file-name= doesn't work well for other files in mac m1. According to my experiment, in linux, it works well to return the path as:

/disk2/workspace.xuchuanqi/llvm-project-for-work/build_clang_libcxx/installed/bin/../lib/x86_64-unknown-linux-gnu/libc++.modules.json

but in mac m1, the libc++ modules json file is installed to

<install-dir>/lib/libc++.modules.json

then x86_64-unknown-linux-gnu becomes a significant change. I am not sure if this is the root of the cause.

llvmbot · 2024-09-25T05:33:18Z

@llvm/issue-subscribers-clang-driver

Author: Chuanqi Xu (ChuanqiXu9)

I received a private report that `-print-file-name=libc++.modules.json` doesn't work well in mac m1. Maybe this is related to the installation path of libc++ in MacOS.

Verify needed.

ChuanqiXu9 · 2024-09-25T05:33:29Z

I guess we need help from Apple's people @Bigcheese @jansvoboda11 @ldionne

billhoffman · 2024-09-27T17:49:33Z

Not sure if this helps but:

% clang++ -print-file-name=libc++.modules.json
libc++.modules.json
% clang++ -print-file-name=../../libc++.modules.json
/Users/hoffman/Work/llvm/llvm-inst/lib/clang/20/../../libc++.modules.json

clang++ --version
clang version 20.0.0git ([email protected]:llvm/llvm-project.git d5dd7d2)
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /Users/hoffman/Work/llvm/llvm-inst/bin

ldionne · 2024-09-27T19:51:41Z

This seems similar to #98325.

@Xazax-hun Any appetite for this one?

ChuanqiXu9 · 2024-09-29T02:05:35Z

Some additional information about the codes, hope this helps:

The -print-file-name was implemented in Driver::GetFilePath from clang/lib/Driver/Driver.cpp. The key value here are TC.getLibraryPaths() and TC.getFilePaths(). Their values are initialized in ToolChain::ToolChain from clang/lib/Driver/ToolChain.cpp. Note that in the comment of ToolChain::getRuntimePath() it says:

// Darwin and AIX does not use per-target runtime directory.

and in ToolChain::getStdlibPath(), it will add the target triple automatically. So I feel it is broken in mac since day 1. A simple fix may be not to add the target triple in ToolChain::getStdlibPath().

billhoffman · 2024-09-30T16:47:19Z

The following patch seems to work for me:

index efe398dd531d..78d06a68bf0d 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -192,8 +192,12 @@ std::string Driver::GetResourcesPath(StringRef BinaryPath) {
     P = llvm::sys::path::parent_path(Dir);
     // This search path is also created in the COFF driver of lld, so any
     // changes here also needs to happen in lld/COFF/Driver.cpp
-    llvm::sys::path::append(P, CLANG_INSTALL_LIBDIR_BASENAME, "clang",
-                            CLANG_VERSION_MAJOR_STRING);
+    llvm::sys::path::append(P, CLANG_INSTALL_LIBDIR_BASENAME);
+    // Darwin and AIX does not use per-target runtime directory.
+    if (!llvm::Triple(llvm::sys::getProcessTriple()).isOSDarwin()) {
+      llvm::sys::path::append(P, "clang",
+                              CLANG_VERSION_MAJOR_STRING);
+    }
   }

mathstuf · 2024-10-01T17:28:17Z

// Darwin and AIX does not use per-target runtime directory.

if (!llvm::Triple(llvm::sys::getProcessTriple()).isOSDarwin()) {

A minor nit: the comment mentions AIX but the code doesn't.

billhoffman · 2024-10-01T17:34:42Z

// Darwin and AIX does not use per-target runtime directory.

if (!llvm::Triple(llvm::sys::getProcessTriple()).isOSDarwin()) {

A minor nit: the comment mentions AIX but the code doesn't.

Yes, I think the code should be updated to do the same for AIX, this comment was copied from another location. Wanted to make sure this is the right approach before cleaning it up. If this looks good to @ChuanqiXu9 and others, I can make a PR with cleaned up code.

ChuanqiXu9 · 2024-10-08T01:36:49Z

It looks good to me. But I think we need double check from apple forks or Driver owners @jansvoboda11 @Bigcheese @MaskRay

billhoffman · 2024-10-09T15:11:39Z

Any way to move this along? Should I just create a PR?

ldionne · 2024-10-09T19:13:34Z

I think that would be the quickest way to ensure this gets addressed, since you already have the patch.

ChuanqiXu9 · 2024-10-10T01:38:26Z

Yes, +1

billhoffman · 2024-10-13T21:53:29Z

Oh dear... I created a fork and went to compile and now I am getting a new error. This is from the bootstrapped compiler not being able to find stdbool.h. I think it is some update of xcode that has caused this. Anyone seen this?
/Users/hoffman/Work/llvm/llvm-project/libunwind/src/UnwindLevel1.c:23:10: fatal error: 'stdbool.h' file not found

ChuanqiXu9 · 2024-10-14T01:37:56Z

I didn't see it. But I think we didn't force contributors to bootstrap their build as far as I know. So maybe we can workaround that.

billhoffman · 2024-10-14T17:41:11Z

I created an issue: #112151 (comment)

billhoffman · 2024-10-14T18:15:54Z

@ChuanqiXu9 do you know anything about how the default include paths get constructed for the clang that is in the build tree I think I found the issue. See my last comment in the issue I created.

ChuanqiXu9 · 2024-10-15T02:37:35Z

clang/lib/Driver/ToolChain.cpp

I think it is ToolChain::getStdlibIncludePath()

billhoffman · 2024-10-15T22:15:30Z

OK, the patch is what is breaking the build. So, my patch does not work. I think perhaps the location of libc++.modules.json should be changed on the mac to match where it is on linux, so that this works.

billhoffman · 2024-10-16T18:01:48Z

@petrhosek can you look at this? I think it is related to the install location of libc++.modules.json. Using git blame I can see you put this code in: if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE) I am guessing the NOT APPLE is what is causing the difference.

billhoffman · 2024-10-17T19:18:54Z

OK, I have another possible patch. This one does not break the build.

diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 9878a9dad78d..b3ef6aaf5d06 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -6205,6 +6205,11 @@ std::string Driver::GetFilePath(StringRef Name, const Too
lChain &TC) const {
   if (llvm::sys::fs::exists(Twine(R)))
     return std::string(R);
 
+  SmallString<128> R2(ResourceDir);
+  llvm::sys::path::append(R2, "..", "..", Name);
+  if (llvm::sys::fs::exists(Twine(R2)))
+    return std::string(R2);
+
   SmallString<128> P(TC.getCompilerRTPath());
   llvm::sys::path::append(P, Name);
   if (llvm::sys::fs::exists(Twine(P)))

ChuanqiXu9 · 2024-10-18T01:43:04Z

OK, I have another possible patch. This one does not break the build.

diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 9878a9dad78d..b3ef6aaf5d06 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -6205,6 +6205,11 @@ std::string Driver::GetFilePath(StringRef Name, const Too
lChain &TC) const {
   if (llvm::sys::fs::exists(Twine(R)))
     return std::string(R);
 
+  SmallString<128> R2(ResourceDir);
+  llvm::sys::path::append(R2, "..", "..", Name);
+  if (llvm::sys::fs::exists(Twine(R2)))
+    return std::string(R2);
+
   SmallString<128> P(TC.getCompilerRTPath());
   llvm::sys::path::append(P, Name);
   if (llvm::sys::fs::exists(Twine(P)))

Although it might be a little bit add hoc, it is much better than the existing status. I think you can send a PR after you add a test. For the test, you can take a look at: clang/test/Driver/modules-print-library-module-manifest-path.cpp

billhoffman · 2024-10-18T14:58:31Z

Yeah, it did feel a bit ugly. But I think this is a new place for files like this to be found. There is actually some code right above this that looks in "..", just not "../..". Clearly the test is bad, I will see if I can get a test in there that fails the way it is now.

billhoffman · 2024-10-30T21:12:35Z

@ChuanqiXu9 I had some time to look at the test a bit more and I think I see why it is passing when it should not. It is hard coded to only work for linux.
https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/modules-print-library-module-manifest-path.cpp#L14

// RUN: touch %t/Inputs/usr/lib/x86_64-linux-gnu/libc++.modules.json
// RUN: %clang -print-library-module-manifest-path \
// RUN:     -stdlib=libc++ \
// RUN:     -resource-dir=%t/Inputs/usr/lib/x86_64-linux-gnu \
// RUN:     --target=x86_64-linux-gnu 2>&1 \
// RUN:   | FileCheck libcxx.cpp

It basically creates a libc++.modules.json file in a temp dir. Then finds it. Of course this matches what we are seeing that this only works for x86_64 linux as that is all that is being tested. I guess I could work on a version that finds the one in the real build tree and not a mock one, but is that done in clang? @ChuanqiXu9 looks like you wrote this test, so perhaps you can help me figure out how to fix it?

Maybe something like this:

// RUN: %clang -print-file-name=libc++.modules.json \
// RUN:   | FileCheck libcxx.cpp.actual

But not sure how to come up with the regex that would work for all builds to put in libcxx.cpp.actual.

ChuanqiXu9 · 2024-10-31T02:47:02Z

I guess I could work on a version that finds the one in the real build tree and not a mock one, but is that done in clang?

No, we shouldn't do this in clang's lit test. We shouldn't lookup the file in the real build tree. Otherwise it will be problematic for other devs if they don't have the same environment.

Maybe something like this:

// RUN: %clang -print-file-name=libc++.modules.json
// RUN: | FileCheck libcxx.cpp.actual
But not sure how to come up with the regex that would work for all builds to put in libcxx.cpp.actual.

So we can't do this. We have to add other arguments to make clang to search the files in the new root we specified.

I think we can improve this by making the mocked tree more real.

billhoffman · 2024-10-31T15:01:15Z

I think we can improve this by making the mocked tree more real.

I am not so sure about that. What if the file is not even installed or created. The way this test worked you would never find that out. Isn't there a way to just run the compiler and get the full path out of it for the actual file and test if that file exists?

billhoffman · 2024-11-26T16:28:47Z

Seems like we could just run the command and make sure the file that it produces actually exists. That should not cause any trouble for any dev or build. Since -print-file-name=libc++.modules.json gives a full path to the file, we should just be able to check and see if it is there or not. If we just try and make the mocked tree more real we will likely miss cases. What if someone changes where it is installed, then the test will pass but the code will be broken.

The following works. It fails before I make my change, and passes with my patch.

// RUN: test -f `%clang -print-library-module-manifest-path`

Issues I can see with this are that test -f would not work on Windows. However, there are a few test -f calls in that test directory so maybe it is ok.

diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index ad14b5c9b6dc..0a181d3edfd3 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -6209,6 +6209,11 @@ std::string Driver::GetFilePath(StringRef Name, const ToolChain &TC) const {
   if (llvm::sys::fs::exists(Twine(R)))
     return std::string(R);
 
+  SmallString<128> R2(ResourceDir);
+  llvm::sys::path::append(R2, "..", "..", Name);
+  if (llvm::sys::fs::exists(Twine(R2)))
+    return std::string(R2);
+  
   SmallString<128> P(TC.getCompilerRTPath());
   llvm::sys::path::append(P, Name);
   if (llvm::sys::fs::exists(Twine(P)))
diff --git a/clang/test/Driver/modules-print-library-module-manifest-path.cpp b/clang/test/Driver/modules-print-library-module-manifest-path.cpp
index 3ba2709ad95c..ca0dd7b726c7 100644
--- a/clang/test/Driver/modules-print-library-module-manifest-path.cpp
+++ b/clang/test/Driver/modules-print-library-module-manifest-path.cpp
@@ -18,6 +18,8 @@
 // RUN:     --target=x86_64-linux-gnu 2>&1 \
 // RUN:   | FileCheck libcxx.cpp
 
+// RUN: test -f `%clang -print-library-module-manifest-path`
+
 // RUN: rm %t/Inputs/usr/lib/x86_64-linux-gnu/libc++.so
 // RUN: touch %t/Inputs/usr/lib/x86_64-linux-gnu/libc++.a
 // RUN: %clang -print-library-module-manifest-path \

ChuanqiXu9 · 2024-11-27T01:43:41Z

I am not so sure about that. What if the file is not even installed or created. The way this test worked you would never find that out.

No, we shouldn't do this in clang. It is best to make the lit test in clang self contained that it may not affect by the environment of different devs.

Isn't there a way to just run the compiler and get the full path out of it for the actual file and test if that file exists?

I don't think we want it in clang lit test. In practice, if any did so, we will receive issue reports.

billhoffman · 2024-11-27T02:11:36Z

My patch and the test do work. If you have another suggestion I would be open to it. However, I think my test should work for all developers.

ChuanqiXu9 · 2024-11-27T02:19:34Z

My patch and the test do work. If you have another suggestion I would be open to it. However, I think my test should work for all developers.

What if the dev doesn't install the std module? Then what's the return value of %clang -print-library-module-manifest-path in that case?

ChuanqiXu9 · 2024-12-19T12:33:29Z

Same with #120215 (comment) to add help wanted label.

billhoffman · 2024-12-19T15:35:03Z

Not surprising to me that it is failing on other systems. Can we set this up so this test is only run when the std module is installed? I don't think it would be possible to correctly simulate this so that it verifies that it works on all platforms unless we actually test the real compiler itself.

ChuanqiXu9 · 2024-12-20T01:58:57Z

Can we set this up so this test is only run when the std module is installed?

I don't think we did this in lit test.

I don't think it would be possible to correctly simulate this so that it verifies that it works on all platforms unless we actually test the real compiler itself.

Test is super important but it has layers. For the in-tree test of clang, we will only do the mocking test. It is not enough for sure. Then we depends on the test from users. Including cmake. e.g., when something go wrong, cmake or any user can report that.

tsunho12 · 2024-12-30T04:49:57Z

I have this problem with Intel Macs as well.

This is because clang++ -print-file-name=libc++.modules.json does not return the full path of “libc++.modules.json” (I don’t know why).

But the workaround is here.

for Intel Mac
– Open the file “/usr/local/Cellar/cmake/3.31.3/share/cmake/Modules/Compiler/Clang-CXX-CXXImportStd.cmake”

for Apple silicon Mac
– Open the file "/opt/homebrew/Cellar/cmake/some version/share/cmake/Modules/Compiler/Clang-CXX-CXXImportStd.cmake"

– Change line 13
– ” -print-file-name=libc++.modules.json” to ” -print-file-name=../../c++/libc++.modules.json”

billhoffman · 2024-12-31T14:24:08Z

Maybe we should just apply my patch since this isn't tested anyway. It should fix a bunch of issues people are seeing. I seriously don't see how this can be tested correctly without testing the actual install. If anything is changed in the location of where this file goes in the actually install, the tests will keep on passing. We know my patch will fix the issues on Mac.

ChuanqiXu9 · 2025-01-03T01:45:05Z

Maybe we should just apply my patch since this isn't tested anyway. It should fix a bunch of issues people are seeing. I seriously don't see how this can be tested correctly without testing the actual install. If anything is changed in the location of where this file goes in the actually install, the tests will keep on passing. We know my patch will fix the issues on Mac.

We have our policy. It should be tested with a mocked installed layout.

billhoffman · 2025-01-08T20:41:08Z

OK, I think I have it working with a mock test. The test fails without the change to Driver.cpp and passes with it. @ChuanqiXu9 Does this look good? If so, I can do a PR.

diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index ad14b5c9b6dc..37244bd01816 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -6209,6 +6209,11 @@ std::string Driver::GetFilePath(StringRef Name, const T
oolChain &TC) const {
   if (llvm::sys::fs::exists(Twine(R)))
     return std::string(R);
 
+  SmallString<128> R2(ResourceDir);
+  llvm::sys::path::append(R2, "..", "..", Name);
+  if (llvm::sys::fs::exists(Twine(R2)))
+    return std::string(R2);
+
   SmallString<128> P(TC.getCompilerRTPath());
   llvm::sys::path::append(P, Name);
   if (llvm::sys::fs::exists(Twine(P)))
diff --git a/clang/test/Driver/modules-print-library-module-manifest-path.cpp 
b/clang/test/Driver/modules-print-library-module-manifest-path.cpp
index 3ba2709ad95c..8d17fe1549e3 100644
--- a/clang/test/Driver/modules-print-library-module-manifest-path.cpp
+++ b/clang/test/Driver/modules-print-library-module-manifest-path.cpp
@@ -18,6 +18,28 @@
 // RUN:     --target=x86_64-linux-gnu 2>&1 \
 // RUN:   | FileCheck libcxx.cpp
 
+// for macos there is a different directory structure
+// where the library and libc++.modules.json file are in lib
+// directly but headers are in clang/ver directory which
+// is the resource directory
+// RUN: mkdir -p %t/Inputs/usr/lib/clang/20
+// RUN: touch %t/Inputs/usr/lib/libc++.so
+// RUN: touch %t/Inputs/usr/lib/libc++.modules.json
+// RUN: %clang -print-library-module-manifest-path \
+// RUN:     -stdlib=libc++ \
+// RUN:     -resource-dir=%t/Inputs/usr/lib/clang/20 \
+// RUN:     --target=arm64-apple-darwin24.1.0 2>&1 \
+// RUN:   | FileCheck libcxx.cpp.macos
+
+// RUN: rm %t/Inputs/usr/lib/libc++.so
+// RUN: touch %t/Inputs/usr/lib/libc++.a
+// RUN: touch %t/Inputs/usr/lib/libc++.modules.json
+// RUN: %clang -print-library-module-manifest-path \
+// RUN:     -stdlib=libc++ \
+// RUN:     -resource-dir=%t/Inputs/usr/lib/clang/20 \
+// RUN:     --target=arm64-apple-darwin24.1.0 2>&1 \
+// RUN:   | FileCheck libcxx.cpp.macos
+
 // RUN: rm %t/Inputs/usr/lib/x86_64-linux-gnu/libc++.so
 // RUN: touch %t/Inputs/usr/lib/x86_64-linux-gnu/libc++.a
 // RUN: %clang -print-library-module-manifest-path \
@@ -40,6 +62,10 @@
 
 // CHECK: {{.*}}/Inputs/usr/lib/x86_64-linux-gnu{{/|\\}}libc++.modules.json
 
+//--- libcxx.cpp.macos
+
+// CHECK: {{.*}}libc++.modules.json
+
 //--- libcxx-no-shared-lib.cpp
 
 // Note this might find a different path depending whether search path

ChuanqiXu9 · 2025-01-09T01:57:24Z

OK, I think I have it working with a mock test. The test fails without the change to Driver.cpp and passes with it. @ChuanqiXu9 Does this look good? If so, I can do a PR.

diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index ad14b5c9b6dc..37244bd01816 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -6209,6 +6209,11 @@ std::string Driver::GetFilePath(StringRef Name, const T
oolChain &TC) const {
   if (llvm::sys::fs::exists(Twine(R)))
     return std::string(R);
 
+  SmallString<128> R2(ResourceDir);
+  llvm::sys::path::append(R2, "..", "..", Name);
+  if (llvm::sys::fs::exists(Twine(R2)))
+    return std::string(R2);
+
   SmallString<128> P(TC.getCompilerRTPath());
   llvm::sys::path::append(P, Name);
   if (llvm::sys::fs::exists(Twine(P)))
diff --git a/clang/test/Driver/modules-print-library-module-manifest-path.cpp 
b/clang/test/Driver/modules-print-library-module-manifest-path.cpp
index 3ba2709ad95c..8d17fe1549e3 100644
--- a/clang/test/Driver/modules-print-library-module-manifest-path.cpp
+++ b/clang/test/Driver/modules-print-library-module-manifest-path.cpp
@@ -18,6 +18,28 @@
 // RUN:     --target=x86_64-linux-gnu 2>&1 \
 // RUN:   | FileCheck libcxx.cpp
 
+// for macos there is a different directory structure
+// where the library and libc++.modules.json file are in lib
+// directly but headers are in clang/ver directory which
+// is the resource directory
+// RUN: mkdir -p %t/Inputs/usr/lib/clang/20
+// RUN: touch %t/Inputs/usr/lib/libc++.so
+// RUN: touch %t/Inputs/usr/lib/libc++.modules.json
+// RUN: %clang -print-library-module-manifest-path \
+// RUN:     -stdlib=libc++ \
+// RUN:     -resource-dir=%t/Inputs/usr/lib/clang/20 \
+// RUN:     --target=arm64-apple-darwin24.1.0 2>&1 \
+// RUN:   | FileCheck libcxx.cpp.macos
+
+// RUN: rm %t/Inputs/usr/lib/libc++.so
+// RUN: touch %t/Inputs/usr/lib/libc++.a
+// RUN: touch %t/Inputs/usr/lib/libc++.modules.json
+// RUN: %clang -print-library-module-manifest-path \
+// RUN:     -stdlib=libc++ \
+// RUN:     -resource-dir=%t/Inputs/usr/lib/clang/20 \
+// RUN:     --target=arm64-apple-darwin24.1.0 2>&1 \
+// RUN:   | FileCheck libcxx.cpp.macos
+
 // RUN: rm %t/Inputs/usr/lib/x86_64-linux-gnu/libc++.so
 // RUN: touch %t/Inputs/usr/lib/x86_64-linux-gnu/libc++.a
 // RUN: %clang -print-library-module-manifest-path \
@@ -40,6 +62,10 @@
 
 // CHECK: {{.*}}/Inputs/usr/lib/x86_64-linux-gnu{{/|\\}}libc++.modules.json
 
+//--- libcxx.cpp.macos
+
+// CHECK: {{.*}}libc++.modules.json
+
 //--- libcxx-no-shared-lib.cpp
 
 // Note this might find a different path depending whether search path

Thanks. It looks good to me.

billhoffman · 2025-01-09T20:56:56Z

@ChuanqiXu9 here is the PR #122370

ChuanqiXu9 added clang:modules platform:macos labels Sep 25, 2024

ChuanqiXu9 added the libc++ label Sep 25, 2024

ChuanqiXu9 changed the title ~~[modules] -print-file-name=libc++.modules.json does not work in mac~~ [modules] -print-file-name=libc++.modules.json does not work in mac m1 Sep 25, 2024

ChuanqiXu9 added the clang:driver label Sep 25, 2024

billhoffman mentioned this issue Oct 15, 2024

Compile fails with LLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libc;libunwind" on Mac M1 #112151

Closed

ChuanqiXu9 mentioned this issue Dec 19, 2024

libc++.modules.json resource does not exist #120215

Open

ChuanqiXu9 added the help wanted label Dec 19, 2024

[modules] -print-file-name=libc++.modules.json does not work in mac m1 #109895

[modules] -print-file-name=libc++.modules.json does not work in mac m1 #109895

Comments

ChuanqiXu9 commented Sep 25, 2024 • edited Loading

llvmbot commented Sep 25, 2024

ChuanqiXu9 commented Sep 25, 2024

llvmbot commented Sep 25, 2024

ChuanqiXu9 commented Sep 25, 2024

billhoffman commented Sep 27, 2024

ldionne commented Sep 27, 2024

ChuanqiXu9 commented Sep 29, 2024

billhoffman commented Sep 30, 2024

mathstuf commented Oct 1, 2024

billhoffman commented Oct 1, 2024

ChuanqiXu9 commented Oct 8, 2024

billhoffman commented Oct 9, 2024

ldionne commented Oct 9, 2024

ChuanqiXu9 commented Oct 10, 2024

billhoffman commented Oct 13, 2024 • edited Loading

ChuanqiXu9 commented Oct 14, 2024

billhoffman commented Oct 14, 2024

billhoffman commented Oct 14, 2024

ChuanqiXu9 commented Oct 15, 2024

billhoffman commented Oct 15, 2024

billhoffman commented Oct 16, 2024

billhoffman commented Oct 17, 2024

ChuanqiXu9 commented Oct 18, 2024

billhoffman commented Oct 18, 2024

billhoffman commented Oct 30, 2024

ChuanqiXu9 commented Oct 31, 2024

billhoffman commented Oct 31, 2024

billhoffman commented Nov 26, 2024 • edited Loading

ChuanqiXu9 commented Nov 27, 2024

billhoffman commented Nov 27, 2024

ChuanqiXu9 commented Nov 27, 2024

ChuanqiXu9 commented Dec 19, 2024

billhoffman commented Dec 19, 2024

ChuanqiXu9 commented Dec 20, 2024

tsunho12 commented Dec 30, 2024 • edited Loading

billhoffman commented Dec 31, 2024

ChuanqiXu9 commented Jan 3, 2025

billhoffman commented Jan 8, 2025 • edited Loading

ChuanqiXu9 commented Jan 9, 2025

billhoffman commented Jan 9, 2025

ChuanqiXu9 commented Sep 25, 2024 •

edited

Loading

billhoffman commented Oct 13, 2024 •

edited

Loading

billhoffman commented Nov 26, 2024 •

edited

Loading

tsunho12 commented Dec 30, 2024 •

edited

Loading

billhoffman commented Jan 8, 2025 •

edited

Loading