https://github.com/jhuber6 approved this pull request.
Makes sense, though I don't know why we have a special flag for what is
essentially a header.
https://github.com/llvm/llvm-project/pull/131017
___
cfe-commits mailing list
cfe-commits@lists.llvm.o
https://github.com/jhuber6 approved this pull request.
Fine way to show the intrinsics that this generates. I originally kept it brief
since I just assumed those were tested elsewhere.
https://github.com/llvm/llvm-project/pull/130956
___
cfe-commits m
https://github.com/jhuber6 approved this pull request.
This means that `nvptxintrin.h` and `amdgpuintrin.h` can't be included
standalone, but I'm not sure it's a big deal since we already define a lot of
the common functionality in the `gpurintrin.h` header.
https://github.com/llvm/llvm-projec
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/131023
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> Yeah these are implemented in bitcode file, therefore it needs the front end
> to be able to recognize it instead of treating it as an unknown symbol.
In a normal world they would just be in a header and then the library would get
linked in later.
https://github.com/llvm/llvm
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/126143
>From 43bb8a63bf008bf08bae03e4e64cf76e32e77ea5 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Feb 2025 15:54:19 -0600
Subject: [PATCH] [OpenMP] Remove 'libomptarget.devicertl.a' fatbinary and use
stat
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/126143
>From 923b58bec55e1956b1ef9379cb1053e060bcb2e4 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Feb 2025 15:54:19 -0600
Subject: [PATCH] [OpenMP] Remove 'libomptarget.devicertl.a' fatbinary and use
stat
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/127082
Summary:
Currently we force this to be off in `-cc1`, but I feel like this should
be something the driver informs the compiler of. It's not
*inconcievable* that RTTI might 'work' on the GPU some day, but mostly I
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/127082
>From 508e938558ac3fb73f0e5389da362b18bef56ce0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 13 Feb 2025 09:27:24 -0600
Subject: [PATCH] [Clang] Disable RTTI for offloading at the frontend level
Summar
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/127082
>From 337ac857a8139eb0ee24effba0fa1d8fa8eaca28 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 13 Feb 2025 09:27:24 -0600
Subject: [PATCH] [Clang] Disable RTTI for offloading at the frontend level
Summar
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/127082
>From 1484f19a1b959981b89187cc0edc7bc370427fe3 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 13 Feb 2025 09:27:24 -0600
Subject: [PATCH] [Clang] Disable RTTI for offloading at the frontend level
Summar
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/127082
>From b17f35541bb5de23389afe0af61cda2cac749e81 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 13 Feb 2025 09:27:24 -0600
Subject: [PATCH] [Clang] Disable RTTI for offloading at the frontend level
Summar
jhuber6 wrote:
@AlexVlx I found this breaks my clang build, reduced the C++ source to the
following reproducer https://godbolt.org/z/jGnvKeqvr. Please verify that it
breaks for you as well and revert or fix.
https://github.com/llvm/llvm-project/pull/114062
_
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/127890
>From d5efc8e10fabb0f2258e0bf5d2e4ce9c0686b911 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 19 Feb 2025 14:01:56 -0600
Subject: [PATCH 1/4] [Clang][Docs] Document -Xarch_ better
Summary:
This argument
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/127890
>From d5efc8e10fabb0f2258e0bf5d2e4ce9c0686b911 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 19 Feb 2025 14:01:56 -0600
Subject: [PATCH 1/2] [Clang][Docs] Document -Xarch_ better
Summary:
This argument
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/127890
>From d5efc8e10fabb0f2258e0bf5d2e4ce9c0686b911 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 19 Feb 2025 14:01:56 -0600
Subject: [PATCH 1/3] [Clang][Docs] Document -Xarch_ better
Summary:
This argument
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/127703
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/127890
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/127890
Summary:
This argument is esoteric and previously didn't even work consistently
across the targets. Now that's fixed we should document it better.
>From a7be26f70a9ba9a381e91b4c6257dc173444c6ef Mon Sep 17 00:00
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/127890
>From d5efc8e10fabb0f2258e0bf5d2e4ce9c0686b911 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 19 Feb 2025 14:01:56 -0600
Subject: [PATCH] [Clang][Docs] Document -Xarch_ better
Summary:
This argument is
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/127890
>From d5efc8e10fabb0f2258e0bf5d2e4ce9c0686b911 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 19 Feb 2025 14:01:56 -0600
Subject: [PATCH 1/5] [Clang][Docs] Document -Xarch_ better
Summary:
This argument
jhuber6 wrote:
> While I was working on the tests, I realised I can no longer replicate this
> issue in main. I guess it got fixed by someone, somewhere. I'm gonna close
> this now.
I'm not aware of any changes in this area, but if it doesn't fail anymore I
guess that's fine.
https://github.
jhuber6 wrote:
> As for next steps, I think we need a broader community discussion on this, so
> I would recommend an RFC proposing an approach. I don't know whether that's
> changing the behavior of `__has_builtin`, proposing `__can_use_builtin` and
> deprecating `__has_builtin`, or something
@@ -27,6 +27,8 @@
extern "C" {
#endif
+#if !defined(__CUDA__)
jhuber6 wrote:
We'd want this to compile for the CUDA host, you should be able to check
`__CUDA_ARCH__` for the CUDA device only.
https://github.com/llvm/llvm-project/pull/128222
https://github.com/jhuber6 approved this pull request.
Maybe a comment for why we need to check for the CUDA arch, but I'll defer to
@Artem-B for the final +1.
https://github.com/llvm/llvm-project/pull/128222
___
cfe-commits mailing list
cfe-commits@l
@@ -0,0 +1,38 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --include-generated-funcs --version 5
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple amdgcn-amd-amdhsa
-fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-t
@@ -0,0 +1,38 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --include-generated-funcs --version 5
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple amdgcn-amd-amdhsa
-fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-t
jhuber6 wrote:
/cherry-pick
https://github.com/llvm/llvm-project/commit/6cc7ca084a5bbb7ccf606cab12065604453dde59
https://github.com/llvm/llvm-project/pull/127703
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/128569
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> @JonChesterfield even if you distinguish spirv64 from amdgpu in cmake clang
> doesn't make that distinction. A common pattern for spriv64 is to return null
> if its not AMDGPU.
General question, what's the expected way to access things like thread IDs and
such from SPIR-V? Th
jhuber6 wrote:
I'd vote for fixing the CUDA on Arm case that failed in the meantime, then make
a decision as to whether or not we should go back to `__has_builtin` only
returning the current compilation target once that's gone.
https://github.com/llvm/llvm-project/pull/126324
_
@@ -932,9 +932,18 @@ def W_Joined : Joined<["-"], "W">, Group,
def Xanalyzer : Separate<["-"], "Xanalyzer">,
HelpText<"Pass to the static analyzer">, MetaVarName<"">,
Group;
-def Xarch__ : JoinedAndSeparate<["-"], "Xarch_">, Flags<[NoXarchOption]>,
- HelpText<"Pass to th
https://github.com/jhuber6 approved this pull request.
I think it's reasonable and we should probably get this in before the release
window.
https://github.com/llvm/llvm-project/pull/128166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
https://github.com/jhuber6 milestoned
https://github.com/llvm/llvm-project/pull/128166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2266,8 +2266,10 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned
BuiltinID, CallExpr *TheCall) {
if (CheckVectorElementCallArgs(&SemaRef, TheCall))
return true;
if (SemaRef.BuiltinElementwiseTernaryMath(
-TheCall, /*CheckForFloatArgs*/
-
@@ -515,17 +515,19 @@ void tools::AddLinkerInputs(const ToolChain &TC, const
InputInfoList &Inputs,
//
// 1. On Linux, link only when actually needed.
//
- // 2. Prefer libm functions over libamath.
+ // 2. Prefer libm functions over libamath (when
@@ -116,11 +116,17 @@
/// Verify that vectorized routines library is being linked in.
// RUN: %clang -### --target=aarch64-pc-windows-msvc -fveclib=ArmPL %s 2>&1 |
FileCheck --check-prefix=CHECK-LINKING-ARMPL-MSVC %s
// RUN: %clang -### --target=aarch64-linux-gnu -fveclib=ArmP
@@ -515,17 +515,19 @@ void tools::AddLinkerInputs(const ToolChain &TC, const
InputInfoList &Inputs,
//
// 1. On Linux, link only when actually needed.
//
- // 2. Prefer libm functions over libamath.
+ // 2. Prefer libm functions over libamath (when
https://github.com/jhuber6 approved this pull request.
I guessing we pass `-lm` twice here to work around `ld.bfd` not handling static
libraries in a pleasant way?
https://github.com/llvm/llvm-project/pull/133578
___
cfe-commits mailing list
cfe-commi
https://github.com/jhuber6 commented:
So, the main benefit of this is that is can parallelize the linker jobs? Doing
that requires a special flag passed to the linker wrapper.
https://github.com/llvm/llvm-project/pull/132869
___
cfe-commits mailing li
https://github.com/jhuber6 commented:
Shouldn't we be able to just use LTO after the SPIR-V backend left experimental?
https://github.com/llvm/llvm-project/pull/133797
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
@@ -5384,6 +5384,11 @@ LangAS CodeGenModule::GetGlobalVarAddressSpace(const
VarDecl *D) {
LangAS AS;
if (OpenMPRuntime->hasAllocateAttributeForGlobalVar(D, AS))
return AS;
+if (LangOpts.OpenMPIsTargetDevice && getTriple().isSPIRV())
jhuber6 w
@@ -5384,6 +5384,11 @@ LangAS CodeGenModule::GetGlobalVarAddressSpace(const
VarDecl *D) {
LangAS AS;
if (OpenMPRuntime->hasAllocateAttributeForGlobalVar(D, AS))
return AS;
+if (LangOpts.OpenMPIsTargetDevice && getTriple().isSPIRV())
+ // SPIR-V globals s
https://github.com/jhuber6 commented:
I think this should be more specific on what `-ffreestanding` actually does.
Namely, removed implicit search paths, link libraries, passes `-fno-builtin`
and lets `int main` function as a normal function.
For the `libc` side, I don't think this makes much
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/132232
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/132037
>From 181315ce22b47a9b75cd60f584dfbcf359659a11 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 19 Mar 2025 09:12:55 -0500
Subject: [PATCH 1/2] [Offload] Handle `BoundArchitecture` for non-GPU targets
Sum
https://github.com/jhuber6 approved this pull request.
LG, thanks
https://github.com/llvm/llvm-project/pull/132252
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Seems something with AArch64 has made the CI unhappy as well.
https://github.com/llvm/llvm-project/pull/132252
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/133522
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/132870
>From e2bd8c7e4f741fa29f24bdee9073ccf4afecf381 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Mar 2025 22:36:04 -0500
Subject: [PATCH] [Clang][AMDGPU] Remove special handling for COV4 libraries
Summa
@@ -585,6 +597,23 @@ Value *CodeGenFunction::EmitAMDGPUBuiltinExpr(unsigned
BuiltinID,
llvm::Value *Env = EmitScalarExpr(E->getArg(0));
return Builder.CreateCall(F, {Env});
}
+ case AMDGPU::BI__builtin_amdgcn_processor_is: {
+assert(CGM.getTriple().isSPIRV() &&
https://github.com/jhuber6 approved this pull request.
Alright, LG.
Unrelated, but it would be nice if someone who knows SPIR-V better could look
at adding similar builtins for the ones we need to get it working through
OpenMP. I've landed some merges that should make that work, but it seems t
jhuber6 wrote:
> I'm confused about where this leaves the device library build. It's still
> using the none code object version flag, and IIRC it had a mix of its own
> reimplementation of this plus use of some of the builtins.
Hm, you're probably right that the ROCm DL was relying on the spli
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/133164
>From 8c8885d486ac72145d7fd7ba003db7ea9ab17a1f Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 26 Mar 2025 16:03:20 -0500
Subject: [PATCH 1/3] [Clang] Make `--lto-partitions` only default for HIP
Summary
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/133164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/132814
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/129347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> Would it be ok if we prefixed all of these files in `TargetBuiltins` with CG?
> #133199
>
> Building using AppleClang seems to be upset that a cpp file with this name
> already exists. I'm assuming its talking about all the files in
> `clang/lib/Basic/Targets/`. For example t
@@ -0,0 +1,64 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --check-globals all --version 5
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -target-cpu gfx900 -emit-llvm %s
-o - | FileCheck --check-prefix=AMDGCN-GFX900 %s
+// RUN: %cla
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/132037
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1026,6 +1026,12 @@ void Clang::AddPreprocessingOptions(Compilation &C,
const JobAction &JA,
CmdArgs.push_back("-dependency-file");
CmdArgs.push_back(DepFile);
}
+// Cmake generates dependency files using all compilation options specified
+// by user
jhuber6 wrote:
I *really* wish someone from NVIDIA would just fix this stupid limitation
already. @EthanLuisMcDonough This type of stuff shows up for things like this.
Any way we can modify the source code to work around this? It's fine to put it
in a separate global.
```
int arr[] = {1, arr[0
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/133776
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
Right now this checks for `libc++` less than 14. Is that still relevant
following that change?
https://github.com/llvm/llvm-project/pull/139164
___
cfe-commits mailing list
cfe-commits@lists.llvm.
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/139164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/139277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> @jhuber6 do you think can we use `native` instead? I think it would be a
> somewhat better option here. If we have to choose a GPU variant by default,
> we may as well choose the actual GPU, rather than a conditional choice
> between generic SPIR-V or an old GPU, which has the
jhuber6 wrote:
> @jhuber6 Was the follow-up for this backported too?
I don't remember, sorry. I think the whole thing got reverted or something?
https://github.com/llvm/llvm-project/pull/127528
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
jhuber6 wrote:
> > The main obstacle of letting clang emit error when `--offload-arch` is not
> > specified is HIP apps using hipcc as CMAKE_CXX_COMPILER. hipcc adds -xhip
> > by default for .cpp programs. This is a known and long existing issue.
> > Another option is to have multiple `--offloa
jhuber6 wrote:
> > It's just the AMDGCN target without any `+features`, right? The only issue
> > I was aware of was assuming w64 when unspecified but you fixed that
> > previously.
>
> Almost, but it's problematic in several ways. The problems multiply once you
> start adding in manually spe
https://github.com/jhuber6 approved this pull request.
The changes make sense for just adding it, but does it actually work? The CMake
I've seen in `libclc` does multiple compilations and some with
`--target=amdgcn` for example, which is a little different from how the
runtimes builds handle i
@@ -35,7 +35,7 @@ list(INSERT CMAKE_MODULE_PATH 0
# We order libraries to mirror roughly how they are layered, except that
compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES
"libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;offload")
+s
jhuber6 wrote:
Also, if you're compiling C++26, why is it enabling OpenCL language features?
You can already do this pretty easily with `clang --target=spirv64` so long as
you're okay with using vendor intrinsic extensions in SPIR-V. That's pretty
much what the HIP support for SPIR-V does anyw
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/141574
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> This commit breaks a critical optimization for us. We have a project that
> compiles most of the C++26 language features to Vulkan SPIRV.
I've thought about doing that, since I've spent a few years just using normal
C++ to write GPU runtimes. The main issue right now is that t
jhuber6 wrote:
> That said, I don't believe it "works" in the way it's supposed to. It still
> grabs the host tools using `get_host_tool_path` in CMake, and custom commands
> to build with that. I take it we're supposed to use `CMAKE_C_COMPILER` as if
> we were a regular CMake project? Are we
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/141142
>From a45dc43315631f28ced9cf5a14890e46e011e6d2 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 22 May 2025 16:21:34 -0500
Subject: [PATCH] [OpenMP] Fix atomic compare handling with overloaded
operators
@@ -12062,32 +12154,56 @@ bool
OpenMPAtomicCompareCaptureChecker::checkForm3(IfStmt *S,
X = BO->getLHS();
D = BO->getRHS();
- auto *Cond = dyn_cast(S->getCond());
- if (!Cond) {
+ if (auto *Cond = dyn_cast(S->getCond())) {
+C = Cond;
+if (Cond->getOpcode() != B
@@ -991,3 +991,34 @@ int mixed() {
// expected-note@+1 {{in instantiation of function template specialization
'mixed' requested here}}
return mixed();
}
+
+#ifdef OMP51
+struct U {};
+struct U operator<(U, U);
+struct U operator>(U, U);
+struct U operator==(U, U);
+
+templ
jhuber6 wrote:
> I'll need to look into that - maybe we can talk offline. Since `libclc` is
> used by downstream toolchains I feel it'll be hard to significantly change
> how it's built or presented to the host. We could support two methods of
> building but that would get sticky pretty quickl
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/141142
>From f2c18ba64744320a8e2a63938b17137a1b6e74d7 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 22 May 2025 16:21:34 -0500
Subject: [PATCH] [OpenMP] Fix atomic compare handling with overloaded
operators
@@ -12062,32 +12154,56 @@ bool
OpenMPAtomicCompareCaptureChecker::checkForm3(IfStmt *S,
X = BO->getLHS();
D = BO->getRHS();
- auto *Cond = dyn_cast(S->getCond());
- if (!Cond) {
+ if (auto *Cond = dyn_cast(S->getCond())) {
+C = Cond;
+if (Cond->getOpcode() != B
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/141142
>From 07caec33a1113602f3d6ba79357edeae6b66647c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 22 May 2025 16:21:34 -0500
Subject: [PATCH] [OpenMP] Fix atomic compare handling with overloaded
operators
jhuber6 wrote:
> > Hmm, in what cases is `-nogpuinc` added when we don't actually want it? I
> > think we should avoid adding `-nogpuinc` if it's not needed, if possible.
>
> comgr is the JIT compiler for HIP on ROCm. comgr uses -nogpuinc by default.
> However, some users of comgr need to over
jhuber6 wrote:
> but there is other comgr user expecting comgr to have -nogpuinc by default.
> changing that will cause regressions.
If `comgr` can have custom flags then you could just pass the 'do not pass
`-nogpuinc` by default' flag presumably.
https://github.com/llvm/llvm-project/pull/14
jhuber6 wrote:
> > > > Hmm, in what cases is `-nogpuinc` added when we don't actually want it?
> > > > I think we should avoid adding `-nogpuinc` if it's not needed, if
> > > > possible.
> > >
> > >
> > > comgr is the JIT compiler for HIP on ROCm. comgr uses -nogpuinc by
> > > default. Howev
https://github.com/jhuber6 approved this pull request.
We'll now be creating the XRayArgs class when we do this every time, but I
don't think it's expensive enough or done enough times to be an issue. Thanks.
https://github.com/llvm/llvm-project/pull/141043
_
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/141043
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -11762,52 +11762,98 @@ bool
OpenMPAtomicCompareChecker::checkCondUpdateStmt(IfStmt *S,
X = BO->getLHS();
- auto *Cond = dyn_cast(S->getCond());
- if (!Cond) {
-ErrorInfo.Error = ErrorTy::NotABinaryOp;
-ErrorInfo.ErrorLoc = ErrorInfo.NoteLoc = S->getCond()->get
@@ -11762,52 +11762,98 @@ bool
OpenMPAtomicCompareChecker::checkCondUpdateStmt(IfStmt *S,
X = BO->getLHS();
- auto *Cond = dyn_cast(S->getCond());
- if (!Cond) {
-ErrorInfo.Error = ErrorTy::NotABinaryOp;
-ErrorInfo.ErrorLoc = ErrorInfo.NoteLoc = S->getCond()->get
https://github.com/jhuber6 approved this pull request.
Looks like a nice cleanup
https://github.com/llvm/llvm-project/pull/74178
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
The `.bc` file for AMDGPU is unused, I'd imagine SPIR-V is as well since its
compilation flow is like AMDGPU.
https://github.com/llvm/llvm-project/pull/141855
___
cfe-commits mailing list
cfe-comm
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/142021
Summary:
This patch identifies the CUDA path that clang used and forwards it to
the linker wrapper. This should make sure that we're using a consistent
CUDA path, but the behavior should be the same for normal us
@@ -72,7 +72,7 @@ else()
# Note that we check this later (for both build types) but we can provide a
# more useful error message when built in-tree. We assume that LLVM tools are
# always available so don't warn here.
- if( NOT clang IN_LIST LLVM_ENABLE_PROJECTS )
+ if(
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/125744
>From ce7701b7c95ee1e59c7942b23833a7a7336abfb7 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 4 Feb 2025 12:06:34 -0600
Subject: [PATCH] Reapply "[AMDGPU] Use the AMDGPUToolChain when targeting
C/C++ di
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/125744
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
2601 - 2696 of 2696 matches
Mail list logo
