@@ -425,17 +425,21 @@ function(add_libclc_builtin_set)
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} )
endif()
- if(CMAKE_HOST_UNIX OR LLVM_USE_SYMLINKS)
-set(LIBCLC_LINK_OR_COPY create_symlink)
- else()
-set(LIBCLC_LINK_OR_COPY copy)
- endif()
-
foreach(
https://github.com/mgorny created
https://github.com/llvm/llvm-project/pull/149728
Fix the symlink creation logic to use relative paths instead of absolute, in
order to ensure that the installed symlinks actually refer to the installed .bc
files rather than the ones from the build directory.
mgorny wrote:
Thx.
https://github.com/llvm/llvm-project/pull/149657
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
This change broke installing symlinks. Now all symlinks are installed pointing
to the build directory, i.e.:
```
-rw-r--r-- 1 root root 13M Jul 19 16:18 amdgcn--amdhsa.bc
lrwxrwxrwx 1 root root 82 Jul 19 16:18 bonaire-amdgcn--.bc ->
/var/tmp/portage/llvm-core/libclc-22.0.0.999
mgorny wrote:
Filed #149657 to fix it.
https://github.com/llvm/llvm-project/pull/148815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny created
https://github.com/llvm/llvm-project/pull/149657
Fix `libclc/utils/CMakeLists.txt` to expose `prepare_builtins_*` variables in
parent scope. This was a regression introduced in #148815 where the code was
moved into subdirectory, and the variables would no lon
mgorny wrote:
Obviously because `set` in a subdirectory doesn't get exposed to parent
`CMakeLists.txt`…
https://github.com/llvm/llvm-project/pull/148815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
mgorny wrote:
This broke the standalone builds on Gentoo Linux amd64:
```
[1566/1676] cd /var/tmp/portage/llvm-core/libclc-22.0.0./work/libclc_build
&& -o
/var/tmp/portage/llvm-core/libclc-22.0.0./work/libclc_build/clspv--.bc
/var/tmp/portage/llvm-core/libclc-22.0.0./work/libclc_b
mgorny wrote:
No problem. I'm sorry to have caused a merge failure on yours.
https://github.com/llvm/llvm-project/pull/146284
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny closed
https://github.com/llvm/llvm-project/pull/146284
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
Hmm, but I see it's already part of #145895 — and I think that PR will apply
cleanly once this change is made, so I think it's better to keep them
separately and focused on a single aspect.
https://github.com/llvm/llvm-project/pull/146284
_
https://github.com/mgorny approved this pull request.
Makes sense to me.
https://github.com/llvm/llvm-project/pull/145895
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
Okay, figured it out after all and filed #146284.
https://github.com/llvm/llvm-project/pull/145731
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny created
https://github.com/llvm/llvm-project/pull/146284
Build the Z3 mock module via CMake rather than compiling it directly in tests.
This ensures that the toolchain file is exported, and therefore fixes testing
for Gentoo multilib. Also, it ensures that the modul
mgorny wrote:
Unfortunately, after fixing the immediate issue I'm hitting another issue:
`%host_cxx` is compiling a 64-bit library when doing `-m32` build for x86 —
meaning the test run now fails due to ABI mismatch:
```
FAIL: Clang :: Analysis/z3-crosscheck-max-attempts.cpp (1537 of 21645)
**
mgorny wrote:
It's rather caused by doing a multilib build — in general you can't really use
`CMAKE_CXX_COMPILER` outside CMake, since CMake is doing some toolchain magic
on that, and you can't reproduce it right in lit. Unfortunately, I can't think
of a good way of determining whether to run
mgorny wrote:
I'm going to try moving the shared object build into CMake.
https://github.com/llvm/llvm-project/pull/145731
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny closed
https://github.com/llvm/llvm-project/pull/146200
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
Thanks for the prompt review!
https://github.com/llvm/llvm-project/pull/146200
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny created
https://github.com/llvm/llvm-project/pull/146200
Fix running tests that require Z3 headers in standalone build. They were
wrongly relying on `Z3_INCLUDE_DIR` being passed through from LLVM, which is
not the case for a standalone build. Instead, perform `find_
mgorny wrote:
> @mgorny I'm pretty sure you have heard of
> [manyclangs](https://github.com/elfshaker/manyclangs). If you bisect clang
> builds, that should come handy. Saved me many hours already - and counting.
I haven't but I doubt they'll help me — this issue seems to surface only with
ou
mgorny wrote:
No problem. I would have submitted a patch earlier but this bisect is literally
taking all my resources.
https://github.com/llvm/llvm-project/pull/145731
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
mgorny wrote:
That's not the correct solution. You either need to export these variables from
LLVM (implying renaming them to prefix with LLVM namespace), or issue another
`find_package()` in clang standalone block.
https://github.com/llvm/llvm-project/pull/146042
_
mgorny wrote:
As I've said, my issue is specific to the standalone build. You install LLVM
first, then build clang against installed LLVM. Installed LLVM configs indicate
whether LLVM was built against Z3, but they don't include internal Z3 lookup
variables.
https://github.com/llvm/llvm-proje
mgorny wrote:
This change broke standalone clang builds:
```
FAIL: Clang :: Analysis/z3/D83660.c (1480 of 21630)
TEST 'Clang :: Analysis/z3/D83660.c' FAILED
Exit Code: 1
Command Output (stderr):
--
rm -rf
/var/tmp/portage/llvm-core/clang-21.0.0./w
mgorny wrote:
Filed https://github.com/llvm/llvm-project/pull/139371
https://github.com/llvm/llvm-project/pull/139131
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
…or I'll try fixing it first, it seems to be a trivial case of missing include.
https://github.com/llvm/llvm-project/pull/139131
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
mgorny wrote:
I'm also seeing this failure, so I'm going to revert.
https://github.com/llvm/llvm-project/pull/139131
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
Yeah, I think it's a good idea. Thanks for doing that!
https://github.com/llvm/llvm-project/pull/138587
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
Honestly, I am thoroughly confused about all that openmp ↔ offload moving. But
if these don't share much code with the current `openmp`, perhaps the cleanest
approach would be to make it entirely separate?
https://github.com/llvm/llvm-project/pull/136729
mgorny wrote:
https://github.com/llvm/llvm-project/pull/136442
https://github.com/llvm/llvm-project/pull/126143
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
Yeah, I can do that. I suppose a separate build would be cleaner in the long
run — and hopefully it will let us build the CPU part cleanly with GCC xP.
https://github.com/llvm/llvm-project/pull/126143
___
cfe-commits mailing list
cfe-com
mgorny wrote:
No, I'm afraid that didn't change anything. However, it did if I added it to
`target_link_options` too.
That said, you want to instead:
```diff
--- a/offload/DeviceRTL/CMakeLists.txt
+++ b/offload/DeviceRTL/CMakeLists.txt
@@ -132,7 +132,7 @@ function(compileDeviceRTLLibrary targe
mgorny wrote:
Yeah, appending `-march=` seems to work.
https://github.com/llvm/llvm-project/pull/126143
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
> It should only be invoking `nvptx-arch` if the user passed `-march=native`.
Sorry, didn't notice this sentence. Well, *I am* building with `-march=native`
here — after all, other files are built for a CPU. If I change it to, say,
`-march=zen2`, then it indeed compiles, with a l
mgorny wrote:
I'm sorry, I've unmerged these packages already after trying an older commit.
Lemme build them again.
https://github.com/llvm/llvm-project/pull/126143
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
mgorny wrote:
How did you disable it? Perhaps it's failing because of the specific error:
```
$ nvptx-arch
Failed to 'dlopen' libcuda.so.1
```
For comparison, `amdgpu-arch` doesn't print
mgorny wrote:
Clang was built from the same commit id
(ee4c8b556c5cf42c55ce9540bbb0e29c11894a71).
https://github.com/llvm/llvm-project/pull/126143
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
mgorny wrote:
Nah, building standalone directly. And separately from OpenMP.
https://github.com/llvm/llvm-project/pull/126143
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
And after switching to clang, it fails anyway:
```
$ /usr/lib/ccache/bin/x86_64-pc-linux-gnu-clang++ -O2 -pipe -march=native
-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs
--target=nvptx64-nvidia-cuda -r -nostdlib -flto -Wl,--lto-emit-llvm
DeviceRTL/Allocator.cpp-nvptx.o
mgorny wrote:
This change broke building with GCC set as the C++ compiler:
```
FAILED: libomptarget-nvptx.bc
: && /usr/lib/ccache/bin/x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native
-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs
--target=nvptx64-nvidia-cuda -r -nostdlib -flto -Wl,--lt
https://github.com/mgorny closed
https://github.com/llvm/llvm-project/pull/127345
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
Closed in favor of #134362.
https://github.com/llvm/llvm-project/pull/127345
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
> I find this change quite confusing. It seems that `-static-libflangrt` now
> expects entirely different install location than `-shared-libflangrt`.
Ah, sorry, now I see that
`-L/usr/lib/llvm/21/bin/../../../../lib/clang/21/lib/x86_64-pc-linux-gnu` is
also added, so the "resour
mgorny wrote:
I find this change quite confusing. It seems that `-static-libflangrt` now
expects entirely different install location than `-shared-libflangrt`.
Furthermore, the location used seems inconsistent with clang, i.e.:
/usr/lib/llvm/21/bin/../../../../lib/clang/21/lib/x86_64-pc-l
mgorny wrote:
This change seems to have broken the test suite:
```
ctest -j 32 --test-load 32
Test project /var/tmp/portage/llvm-core/libclc-21.0.0./work/libclc_build
Start 1: external-calls-tahiti-amdgcn--.bc
Start 2: external-calls-amdgcn--amdhsa.bc
Start 3: external-calls-tahi
https://github.com/mgorny approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/127529
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny approved this pull request.
Thanks for looking into it.
https://github.com/llvm/llvm-project/pull/127515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
Sigh, looks like clang's driver is a mess around `lib`/`lib64` after all. So a
proper solution would probably involve adding arch to the library name, and
moving it into clang's resource directory.
https://github.com/llvm/llvm-project/pull/127345
_
mgorny wrote:
Hmm, but thinking about it, it should probably grab the right libdir from some
multilib config rather than the hardwired build-time value.
https://github.com/llvm/llvm-project/pull/127345
___
cfe-commits mailing list
cfe-commits@lists.ll
mgorny wrote:
> But `lib` is used for 32-bit libraries, and `lib64` for 64-bit libraries.
…and just to be clear, Flang runtimes are installed into plain system
`CMAKE_INSTALL_LIBDIR` rather than `clang/lib/...` path (along with the "host"
Flang libraries), and they don't have any arch-suffix,
mgorny wrote:
But `lib` is used for 32-bit libraries, and `lib64` for 64-bit libraries.
https://github.com/llvm/llvm-project/pull/127345
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny created
https://github.com/llvm/llvm-project/pull/127345
Fix `tools::addFortranRuntimeLibraryPath` to use
`CLANG_INSTALL_LIBDIR_BASENAME` rather than hardwired `lib` directory. This
fixes flang being unable to find its runtime when installed into nonstandard
directory
https://github.com/mgorny edited
https://github.com/llvm/llvm-project/pull/127315
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny created
https://github.com/llvm/llvm-project/pull/127315
Fix `add_libclc_builtin_set` to add an appropriate dependency to either
`clspv-generate_convert.cl` or `generate_convert.cl` based on the `ARCH`
argument, rather than to both unconditionally. This fixes build f
mgorny wrote:
Ah, it's just incorrect dependency. Filed #127315 to fix it.
https://github.com/llvm/llvm-project/pull/124727
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
I'm guessing that both `amdgcn` and `nvptx` targets now require
`clspv-generate_convert.cl`, but the targets for them are defined only when
`clspv` targets are enabled. No clue whether it means that the targets need to
be defined unconditionally, or `clc-convert.cl` skipped when
mgorny wrote:
The same failure also happens when SPIRV targets are disabled.
https://github.com/llvm/llvm-project/pull/124727
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
This change broke standalone libclc builds on Gentoo:
```
make -C
/tmp/portage/llvm-core/libclc-21.0.0_pre20250215/work/libclc_build/gentoo_common_config.cmake
-G Ninja -DCMAKE_INSTALL_PREFIX=/usr
-DLIBCLC_TARGETS_TO_BUILD=spirv-mesa3d-;spirv64-mesa3d-;r600--;amdgcn--;amdgcn-mes
mgorny wrote:
Thanks!
https://github.com/llvm/llvm-project/pull/122928
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
Thanks!
https://github.com/llvm/llvm-project/pull/122928
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny closed
https://github.com/llvm/llvm-project/pull/123455
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny created
https://github.com/llvm/llvm-project/pull/123455
Reverts llvm/llvm-project#122928
From ce83c9470ba1a9860c107d39e60d9148ac009e91 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?=
Date: Sat, 18 Jan 2025 07:59:09 +
Subject: [PATCH] =?UTF-8?q
mgorny wrote:
I'm going to revert because of the buildbot failures.
https://github.com/llvm/llvm-project/pull/122928
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
@jhuber6, since I think this PR makes #119006 obsolete, should I merge that one
while this one's still in the works, or close it?
https://github.com/llvm/llvm-project/pull/119091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
mgorny wrote:
This test is failing on x86: #119979
https://github.com/llvm/llvm-project/pull/119719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -288,18 +258,11 @@ function(compileDeviceRTLLibrary target_cpu target_name
target_triple)
endif()
endfunction()
-# Generate a Bitcode library for all the gpu architectures the user requested.
-add_custom_target(omptarget.devicertl.nvptx)
add_custom_target(omptarget.devi
@@ -288,18 +258,11 @@ function(compileDeviceRTLLibrary target_cpu target_name
target_triple)
endif()
endfunction()
-# Generate a Bitcode library for all the gpu architectures the user requested.
-add_custom_target(omptarget.devicertl.nvptx)
add_custom_target(omptarget.devi
@@ -288,18 +258,11 @@ function(compileDeviceRTLLibrary target_cpu target_name
target_triple)
endif()
endfunction()
-# Generate a Bitcode library for all the gpu architectures the user requested.
-add_custom_target(omptarget.devicertl.nvptx)
add_custom_target(omptarget.devi
@@ -288,18 +258,11 @@ function(compileDeviceRTLLibrary target_cpu target_name
target_triple)
endif()
endfunction()
-# Generate a Bitcode library for all the gpu architectures the user requested.
-add_custom_target(omptarget.devicertl.nvptx)
add_custom_target(omptarget.devi
https://github.com/mgorny approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/111387
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny approved this pull request.
I don't see anything wrong but I don't consider myself an expert either.
https://github.com/llvm/llvm-project/pull/117573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
@@ -0,0 +1 @@
+-ffast-math -lm -lhappy
mgorny wrote:
Could you also include some "positional" `-Wl` flags, like `-Wl,-Bstatic` and
`-Wl,-Bdynamic`?
https://github.com/llvm/llvm-project/pull/117573
___
cfe-commits mail
mgorny wrote:
This change broke installing for us, see bug #115942.
https://github.com/llvm/llvm-project/pull/115885
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny approved this pull request.
I can confirm that libclc builds fine for me, with this patch applied.
https://github.com/llvm/llvm-project/pull/116025
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
@@ -355,11 +355,13 @@ function(add_libclc_builtin_set)
install( FILES ${CMAKE_CURRENT_BINARY_DIR}/${obj_suffix} DESTINATION
"${CMAKE_INSTALL_DATADIR}/clc" )
foreach( a ${ARG_ALIASES} )
set( alias_suffix "${a}-${ARG_TRIPLE}.bc" )
-add_custom_target( ${alias_suffix}
mgorny wrote:
Doesn't it change ABI, though?
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny closed
https://github.com/llvm/llvm-project/pull/111302
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mgorny updated
https://github.com/llvm/llvm-project/pull/111302
From 3e057361eee9fa22f1a666857ce98019aba44ea2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?=
Date: Sat, 5 Oct 2024 18:31:35 +0200
Subject: [PATCH 1/3] [llvm] [Triple] Support *t64 environment
@@ -177,6 +177,7 @@ createTargetCodeGenInfo(CodeGenModule &CGM) {
else if (CodeGenOpts.FloatABI == "hard" ||
(CodeGenOpts.FloatABI != "soft" &&
(Triple.getEnvironment() == llvm::Triple::GNUEABIHF ||
mgorny wrote:
Are you asking i
@@ -177,6 +177,7 @@ createTargetCodeGenInfo(CodeGenModule &CGM) {
else if (CodeGenOpts.FloatABI == "hard" ||
(CodeGenOpts.FloatABI != "soft" &&
(Triple.getEnvironment() == llvm::Triple::GNUEABIHF ||
mgorny wrote:
I'm wondering if
@@ -610,7 +610,8 @@ static llvm::Triple computeTargetTriple(const Driver &D,
if (A->getOption().matches(options::OPT_m64) ||
A->getOption().matches(options::OPT_maix64)) {
AT = Target.get64BitArchVariant().getArch();
- if (Target.getEnvironment() == llvm:
@@ -1283,6 +1283,28 @@ TEST(TripleTest, ParsedIDs) {
EXPECT_EQ(Triple::Linux, T.getOS());
EXPECT_EQ(Triple::PAuthTest, T.getEnvironment());
+ // Gentoo time64 triples
+ T = Triple("i686-pc-linux-gnut64");
+ EXPECT_EQ(Triple::x86, T.getArch());
+ EXPECT_EQ(Triple::PC, T
https://github.com/mgorny updated
https://github.com/llvm/llvm-project/pull/111302
From 3e057361eee9fa22f1a666857ce98019aba44ea2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?=
Date: Sat, 5 Oct 2024 18:31:35 +0200
Subject: [PATCH 1/2] [llvm] [Triple] Support *t64 environment
https://github.com/mgorny updated
https://github.com/llvm/llvm-project/pull/111302
From df75eaa8e0f399a43bde9e60af326f0c91aa7ad4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?=
Date: Sat, 5 Oct 2024 18:31:35 +0200
Subject: [PATCH 1/2] [llvm] [Triple] Support *t64 environment
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -E -dM -triple=i686-pc-linux-gnu < /dev/null | FileCheck
-match-full-lines -check-prefix TIME32 %s
mgorny wrote:
Yeah, I was wondering if it's in the `init.c` tests for a reason.
https://github.com/llvm/llvm-project/pull/111
https://github.com/mgorny created
https://github.com/llvm/llvm-project/pull/111302
Gentoo is planning to introduce a `*t64` suffix for triples that will be used
by 32-bit platforms that use 64-bit `time_t`. Add support for parsing and
accepting these triples, and while at it make clang automat
https://github.com/mgorny approved this pull request.
Thanks! This fixes the problem with standalone builds for me.
https://github.com/llvm/llvm-project/pull/109601
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
mgorny wrote:
This broke standalone clang builds:
```
-- Configuring done (6.4s)
CMake Error at /usr/lib/llvm/20/lib/cmake/llvm/AddLLVM.cmake:587
(add_dependencies):
The dependency target "vt_gen" of target "obj.clangCodeGen" does not exist.
Call Stack (most recent call first):
cmake/module
https://github.com/mgorny approved this pull request.
Seems to make sense and is roughly consistent with the code above.
https://github.com/llvm/llvm-project/pull/107613
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
mgorny wrote:
Sounds like a bug in OpenEmbedded then. CPython installs Python modules in
`/usr/lib`, unconditionally.
https://github.com/llvm/llvm-project/pull/108549
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/mgorny closed
https://github.com/llvm/llvm-project/pull/106612
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Michał Górny
Date: 2024-08-30T16:30:19+02:00
New Revision: 0c4cf79defe30d43279bf4526cdf32b6c7f8a197
URL:
https://github.com/llvm/llvm-project/commit/0c4cf79defe30d43279bf4526cdf32b6c7f8a197
DIFF:
https://github.com/llvm/llvm-project/commit/0c4cf79defe30d43279bf4526cdf32b6c7f8a197.diff
https://github.com/mgorny created
https://github.com/llvm/llvm-project/pull/106612
Install scan-build-py modules into the plain `lib` directory, without
LLVM_LIBDIR_SUFFIX appended, to match the path expected by `intercept-build`
executable. This fixes the program being unable to find its mod
mgorny wrote:
Thanks. I can confirm that the tests pass for me with this change applied.
https://github.com/llvm/llvm-project/pull/99841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
This change seems to have caused test regression. This is Gentoo Linux amd64,
tried LLVM 72d8c2737bb557af9d0c735b9fa30b1b03485627 and 18.1.8.
To reproduce, I've done:
```
cmake -G Ninja "${llvm_project}"/libclc
-DLIBCLC_TARGETS_TO_BUILD="spirv-mesa3d-;spirv64-mesa3d-;r600--;amdg
mgorny wrote:
Thanks. I can confirm that the tests pass for me with the patch applied.
https://github.com/llvm/llvm-project/pull/98525
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
The added test fails on 32-bit x86:
```
FAIL: Clang :: C/C2y/n3244.c (1461 of 20066)
TEST 'Clang :: C/C2y/n3244.c' FAILED
Exit Code: 1
Command Output (stderr):
--
RUN: at line 1:
/var/tmp/portage/sys-devel/clang-19.0.0_pre20240713/work/x/
mgorny wrote:
Thank you.
https://github.com/llvm/llvm-project/pull/97540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mgorny wrote:
This change broke standalone clang builds against installed LLVM, since
`LLVM_SHARE_OUTPUT_INTDIR` is not exported by LLVM and therefore resolves to an
empty path:
```
ninja: error: mkdir(/clang-doc): Permission denied
ninja: build stopped: .
```
Why are you even declaring the d
1 - 100 of 349 matches
Mail list logo
