[PATCH] D151601: [NVPTX] Coalesce register classes for {i16,f16,bf16}, {i32,v2f16,v2bf16}

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. I cannot say that I 100% looked over every line, but in principle this seems fine, and if it's passing TF tests then that's pretty strong evidence this is working. Repository: rG LLVM

[PATCH] D150820: [NVPTX, CUDA] added optional src_size argument to __nvvm_cp_async*

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. Re-approval. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150820/new/ https://reviews.llvm.org/D150820

[PATCH] D150718: [CUDA] Relax restrictions on GPU-side variadic functions

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. OK, sgtm. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150718/new/ https://reviews.llvm.org/D150718

[PATCH] D150718: [CUDA] Relax restrictions on GPU-side variadic functions

jlebar added a comment. This seems a little dangerous -- we're saying the frontend will accept this but we can't generate code for it? What happens if we try to generate code? Do we get some sort of error, or do we silently fail? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST

[PATCH] D149364: [CUDA] Temporarily undefine __noinline__ when including bits/shared_ptr_base.h

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. wow. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D149364/new/ https://reviews.llvm.org/D149364

[PATCH] D141555: [CUDA] added cmath wrappers to unbreak CUDA compilation after D79555

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. LGTM. Do we need changes to the test-suite to cover this too? (test-suite being in a separate repo, so it would be a separate patch.) Repository: rG LLVM Github Monorepo CHANGES SINCE

[PATCH] D121259: [clang] Fix CodeGenAction for LLVM IR MemBuffers

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. Congrats on your first patch! Can Daniele or Shangwu land this for you, or do you need me to? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D120366: [CUDA][SPIRV] Assign global address space to CUDA kernel arguments

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGc2f501f39589: [CUDA][SPIRV] Assign global address space to CUDA kernel arguments (authored by shangwuyao, committed by jlebar). Repository: rG

[PATCH] D120366: [CUDA][SPIRV] Assign global address space to CUDA kernel arguments

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. I'll land this for you. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D120366/new/ https://reviews.llvm.org/D120366

[PATCH] D120366: [CUDA][SPIRV] Assign global address space to CUDA kernel arguments

jlebar added a comment. - What's different in this patch vs the previous one? - *Disabled a hip test on Windows that's breaking on head.* Can you clarify: Is this test broken at HEAD, or does it break with your patch? If it's broken at HEAD, then it should be disabled in a separate patch.

[PATCH] D119207: [CUDA][SPIRV] Assign global address space to CUDA kernel arguments

jlebar added a comment. commit 9de4fc0f2d3b60542956f7e5254951d049edeb1f (HEAD -> main, origin/main, origin/HEAD) Author: Shangwu Yao Date: Thu Feb 17 09:38:06 2022 -0800 [CUDA][SPIRV] Assign global address space to CUDA kernel arguments This patch converts CUDA pointer

[PATCH] D119207: [CUDA][SPIRV] Assign global address space to CUDA kernel arguments

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit rG9de4fc0f2d3b: [CUDA][SPIRV] Assign global address space to CUDA kernel arguments (authored by shangwuyao, committed by

[PATCH] D119207: [CUDA][SPIRV] Assign global address space to CUDA kernel arguments

jlebar added a comment. In D119207#3327476 , @shangwuyao wrote: > Thanks for the review, if it looks good, can we get this to land now? > Otherwise more comments are welcome! I'll land this for you! At some point you should get commit access

[PATCH] D119207: [CUDA][SPIRV] Convert CUDA kernels to SPIR-V kernels

jlebar added inline comments. Comment at: clang/lib/CodeGen/TargetInfo.cpp:10322 ABIArgInfo SPIRVABIInfo::classifyKernelArgumentType(QualType Ty) const { - if (getContext().getLangOpts().HIP) { + if (getContext().getLangOpts().CUDAIsDevice) { // Coerce pointer arguments

[PATCH] D119207: [CUDA][SPIRV] Convert CUDA kernels to SPIR-V kernels

jlebar added a comment. > [CUDA][SPIRV] Convert CUDA kernels to SPIR-V kernels Rephrase this? This patch is about kernel *arguments*, right? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D119207/new/ https://reviews.llvm.org/D119207

[PATCH] D117137: [Driver] Add CUDA support for --offload param

jlebar added a comment. Pushed for Daniele: To github.com:llvm/llvm-project.git 99d2582164c4..6eb826567af0 main -> main Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D117137/new/ https://reviews.llvm.org/D117137

[PATCH] D117137: [Driver] Add CUDA support for --offload param

This revision was automatically updated to reflect the committed changes. Closed by commit rG6eb826567af0: [Driver] Add CUDA support for --offload param (authored by dcastagna, committed by jlebar). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D117137: [Driver] Add a flag cuda-device-triple

jlebar added a comment. I defer to Art. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D117137/new/ https://reviews.llvm.org/D117137 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D114454: [NFC][AIX]Disable unstable CSA tests failing on AIX

jlebar added a comment. > Let me summon them. *I have no memory of this place.* Sorry to disappoint. That blame was four years ago, not counting covid-related time dilation. I do agree that disabling a test just to please a static analyzer is probably not the best way to go. Repository:

[PATCH] D110089: [CUDA] Implement experimental support for texture lookups.

jlebar added a comment. Presumably as a separate commit we should add tests to the test_suite repository to ensure that this at least still compiles with different versions of CUDA? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D110089/new/

[PATCH] D110089: [CUDA] Implement experimental support for texture lookups.

jlebar accepted this revision. jlebar added a comment. Okay, I give up on the phab interface. It's unreadable with all the existing comments and lint errors. Hope you don't mind comments this way. I'm just going to put it all in a giant code block so it doesn't get wrapped or whatever. +//

[PATCH] D110089: [CUDA] Implement experimental support for texture lookups.

jlebar added a comment. > Depending on which particular operation is used, the arguments vary, too. So something like T __nv_tex_surf_handler(name, arg1) { switch (name) { ... default: panic(); } } T __nv_tex_surf_handler(name, arg1, arg2) { switch(...)

[PATCH] D110089: [CUDA] Implement experimental support for texture lookups.

jlebar added a comment. > One alternative would be to use run-time dispatch, but, given that texture > lookup is a single instruction, the overhead would be > substantial-to-prohibitive. I guess I'm confused... Is the parameter value that we're "overloading" on usually/always a constant? In

[PATCH] D108787: [CUDA] Pass ExecConfig through BuildCallToMemberFunction

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. Thanks, Art. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108787/new/ https://reviews.llvm.org/D108787

[PATCH] D100794: [HIP] Support overloaded math functions for hipRTC

jlebar added a comment. Other than the declval issue discussed above, this looks reasonable to me. I don't notice anything wrong with the standard library reimplementations here. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100794/new/ https://reviews.llvm.org/D100794

[PATCH] D100310: Add field designated initializers logic in Tooling/Rename

This revision was automatically updated to reflect the committed changes. Closed by commit rG7dd606889925: [clang-rename] Handle designated initializers. (authored by dcastagna, committed by jlebar). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D100310: Add field designated initializers logic in Tooling/Rename

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. I can't argue with this. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100310/new/ https://reviews.llvm.org/D100310

[PATCH] D97708: [CUDA] Remove `noreturn` attribute from __assertfail().

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. Maybe add a comment on assertfail that we don't want it to be noreturn because blah blah? So someone doesn't come back and add it when we're not looking. :) Repository: rG LLVM Github

[PATCH] D95754: [clang] Print 32 candidates on the first failure, with -fshow-overloads=best.

This revision was automatically updated to reflect the committed changes. Closed by commit rGc90dac27e94e: [clang] Print 32 candidates on the first failure, with -fshow-overloads=best. (authored by jlebar). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D95754: [clang] Print 32 candidates on the first failure, with -fshow-overloads=best.

jlebar added a comment. Thank you for the review! I'll put a note in my cal to land this in a few days if I don't hear from @rsmith Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95754/new/ https://reviews.llvm.org/D95754

[PATCH] D95754: [clang] Print 32 candidates on the first failure, with -fshow-overloads=best.

jlebar added a comment. > I guess I was confused by the function name Haha, two hardest problems in computer science. :) Changed it to `S.Diags.overloadCandidatesShown(ShownOverloads);` Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95754/new/

[PATCH] D95754: [clang] Print 32 candidates on the first failure, with -fshow-overloads=best.

jlebar updated this revision to Diff 325158. jlebar added a comment. Rename noteNumOverloadCandidatesShown -> overloadCandidatesShown. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95754/new/ https://reviews.llvm.org/D95754 Files:

[PATCH] D95754: [clang] Print 32 candidates on the first failure, with -fshow-overloads=best.

jlebar added inline comments. Comment at: clang/lib/Sema/Sema.cpp:2310 + S.Diags.noteNumOverloadCandidatesShown(ShownOverloads); + aaronpuchert wrote: > jlebar wrote: > > aaronpuchert wrote: > > > Why not in the following `if`? I assume we want to show a long

[PATCH] D95754: [clang] Print 32 candidates on the first failure, with -fshow-overloads=best.

jlebar added a comment. Thank you for your comments, Aaron! Comment at: clang/lib/Sema/Sema.cpp:2310 + S.Diags.noteNumOverloadCandidatesShown(ShownOverloads); + aaronpuchert wrote: > Why not in the following `if`? I assume we want to show a long list not >

[PATCH] D95754: [clang] Print 32 candidates on the first failure, with -fshow-overloads=best.

jlebar added a comment. Not sure who can review this, but looking through blame it seems like maybe @aaronpuchert? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95754/new/ https://reviews.llvm.org/D95754

[PATCH] D95754: [clang] Print 32 candidates on the first failure, with -fshow-overloads=best.

jlebar created this revision. jlebar requested review of this revision. Herald added a project: clang. Previously, -fshow-overloads=best always showed 4 candidates. The problem is, when this isn't enough, you're kind of up a creek; the only option available is to recompile with different flags.

[PATCH] D94337: Add cuda header type for cuh files

jlebar added a comment. Hi, welcome! Thank you for the careful and well-motivated first commit. (I also see https://github.com/ccache/ccache/issues/772, hooray for noticing that...) I am also not 100% sure how to write a test, but I think you may be able to observe the effect of your driver

[PATCH] D91807: [CUDA] Unbreak CUDA compilation with -std=c++20

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. How fun. :) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91807/new/ https://reviews.llvm.org/D91807

[PATCH] D91590: [NVPTX] Efficently support dynamic index on CUDA kernel aggregate parameters.

jlebar added a comment. I am legit excited about this if we could figure out how to make it work, but I don't have anything to add beyond what tra said. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91590/new/ https://reviews.llvm.org/D91590

[PATCH] D90409: [HIP] Math Headers to use type promotion

jlebar added a comment. > LGTM. I think the change would make sense for CUDA, too. @jlebar - WDYT? I agree that the C and C++ standard libraries should behave the same in CUDA mode and host mode! But if doing so would make our behavior different than nvcc's, maybe we could emit a warning or

[PATCH] D89832: [CUDA] Extract CUDA version from cuda.h if version.txt is not found

jlebar accepted this revision. jlebar added a comment. LGTM modulo emankov's comment. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89832/new/ https://reviews.llvm.org/D89832 ___ cfe-commits mailing

[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

jlebar accepted this revision. jlebar added inline comments. This revision is now accepted and ready to land. Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8163 "%select{__device__|__global__|__host__|__host__ __device__}0 functions">; -def

[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

jlebar added a comment. Hey, I'm leaving on a vacation tomorrow and didn't have a chance to get to this review today. Is that ok? I'm not bringing my work laptop, but I could look at it on my personal laptop. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D88668: [CUDA] Add support for 11.1

jlebar added a comment. > It looks like 11.1 doesn't have a version.txt file Yikes, this is a problem if we can't tell the difference between CUDA versions! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88668/new/ https://reviews.llvm.org/D88668

[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

jlebar added a comment. > It should. I did mention in a previous comment that > Looks like the > const-ness check should not be there, either. I need to revise the patch. Heh, okay. Sorry I missed that, somehow this patch was confusing to me. > Except that NVCC allows non-const __constant__,

[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

jlebar added a comment. OK, now I'm starting to I understand this change.. Before, in function scope, we allow static const/non-const `__shared__`, and allow static const so long as it's not `__device__` or `__constant__`. - `static` -> error? (I understood us saying above that it is, but now

[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

jlebar added a comment. OK, backing up, what are the semantics of `static` on `__constant__`, `__device__`, and `__shared__`? - My understanding is that `__shared__` behaves the same whether or not it's static. It's not equivalent to `namespace a { __shared__ int c = 4; }`, because that's

[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

jlebar added a comment. wha... As you know, `const` doesn't mean anything, that can be const-casted away. And then you'll be able to observe that this nominally-static variable is just a normal variable. Since this doesn't make sense and contradicts their documentation, I'm tempted to say

[PATCH] D88250: [CUDA] Added dim3/uint3 conversion functions to builtin vars.

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. I know it comes in a separate change, but can we add a check to the test-suite? Comment at: clang/lib/Headers/__clang_cuda_runtime_wrapper.h:381 +__device__ inline

[PATCH] D85236: [CUDA] Work around a bug in rint() caused by a broken implementation provided by CUDA.

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. LGTM, and can we write a test in the test-suite? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85236/new/ https://reviews.llvm.org/D85236

[PATCH] D83893: [CUDA][HIP] Always defer diagnostics for wrong-sided reference

jlebar added a comment. tra and I talked offline and I...think this makes sense. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83893/new/ https://reviews.llvm.org/D83893 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D74384: Use std::foo_t rather than std::foo in LLVM.

jlebar added a comment. In D74384#1872246 , @thakis wrote: > Looks like this broke building on windows with clang-cl as host compiler in > some situations: http://45.33.8.238/win/8160/step_4.txt I'm testing out the following fix, which we verified

[PATCH] D74423: Use C++14-style return type deduction in clang.

This revision was automatically updated to reflect the committed changes. Closed by commit rGac66c61bf946: Use C++14-style return type deduction in clang. (authored by jlebar). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74423/new/

[PATCH] D74412: Fix SFINAE in CFG.cpp.

This revision was automatically updated to reflect the committed changes. Closed by commit rGf0fd852fcd05: Fix SFINAE in CFG.cpp. (authored by jlebar). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74412/new/ https://reviews.llvm.org/D74412 Files:

[PATCH] D74423: Use C++14-style return type deduction in clang.

jlebar created this revision. jlebar added reviewers: bkramer, MaskRay. Herald added a reviewer: martong. Herald added a reviewer: shafik. Herald added subscribers: cfe-commits, martong. Herald added a project: clang. Simplifies the C++11-style "-> decltype(...)" return-type deduction. Note that

[PATCH] D74414: Use std::foo_t rather than std::foo in clang.

This revision was automatically updated to reflect the committed changes. Closed by commit rG027eb71696f6: Use std::foo_t rather than std::foo in clang. (authored by jlebar). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74414/new/

[PATCH] D74412: Fix SFINAE in CFG.cpp.

jlebar updated this revision to Diff 243877. jlebar added a comment. Rebase Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74412/new/ https://reviews.llvm.org/D74412 Files: clang/lib/Analysis/CFG.cpp Index: clang/lib/Analysis/CFG.cpp

[PATCH] D74414: Use std::foo_t rather than std::foo in clang.

jlebar created this revision. jlebar added reviewers: bkramer, MaskRay. Herald added a reviewer: martong. Herald added a reviewer: shafik. Herald added subscribers: cfe-commits, martong. Herald added a project: clang. No functional change. Repository: rG LLVM Github Monorepo

[PATCH] D74412: Fix SFINAE in CFG.cpp.

jlebar created this revision. jlebar added reviewers: bkramer, MaskRay. Herald added subscribers: cfe-commits, martong. Herald added a project: clang. jlebar updated this revision to Diff 243877. jlebar added a comment. Rebase Used std::enable_if without ::type. Repository: rG LLVM Github

[PATCH] D74384: Use std::foo_t rather than std::foo in LLVM.

jlebar added a comment. > Such changes can be risky. Heh, well said. I feel good about it because I found two or three real bugs in clang/llvm as a result of this cleanup. But still, we've got to land it safely... I joined the group; what do I do to get tests run for this? > Hope someone

[PATCH] D69878: Consoldiate internal denormal flushing controls

jlebar added a comment. > AMDGPU wants a distinct control for f32 flushing from f16/f64, and as far as > I can tell the same is true for NVPTX (based on the attribute name). I may be corrected, but I believe nvptx only supports ftz for f32. > Double-precision instructions support subnormal

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

jlebar added a comment. > At [nvcc] from CUDA 10, that's not acceptable as we are declaring two > functions only differ from the return type. It seems CUDA attributes do not > contribute to the function signature. clang is quite different here. Yes, this is an intentional and more relaxed

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

jlebar added a subscriber: rsmith. jlebar added a comment. Here's one for you: __host__ float bar(); __device__ int bar(); __host__ __device__ auto foo() -> decltype(bar()) {} What is the return type of `foo`? :) I don't believe the right answer is, "float when compiling for host, int

[PATCH] D59900: [Sema] Fix a crash when nonnull checking

jlebar added a comment. I uh... I also think this is an @rsmith question, I have no idea. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59900/new/ https://reviews.llvm.org/D59900 ___ cfe-commits

[PATCH] D59647: [CUDA][HIP] Warn shared var initialization

jlebar added a comment. > By default it is still treated as error, therefore no behavior change of > clang. Oh, I see, you already did what I'd suggested. :) That's better. I think this needs to be made *much scarier* though. "Maybe race condition" doesn't capture the danger here -- you

[PATCH] D59647: [CUDA][HIP] Warn shared var initialization

jlebar requested changes to this revision. jlebar added a comment. This revision now requires changes to proceed. I agree with Art. The fact that nvcc allows this is broken. If you want a flag that makes this error a warning, that might work for me. The flag should probably say "unsafe" or "I

[PATCH] D57771: [CUDA] Add basic support for CUDA-10.1

jlebar accepted this revision. jlebar added inline comments. This revision is now accepted and ready to land. Comment at: clang/lib/CodeGen/CGCUDANV.cpp:620 + +// CUDA version requires calling __cudaRegisterFatBinaryEnd(Handle); +if

[PATCH] D57488: [CUDA] add support for the new kernel launch API in CUDA-9.2+.

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. LGTM, mostly nits. Comment at: clang/include/clang/Sema/Sema.h:10316 + /// Returns the name of the launch configuration function. + std::string

[PATCH] D57487: [CUDA] Propagate detected version of CUDA to cc1

jlebar accepted this revision. jlebar added inline comments. This revision is now accepted and ready to land. Comment at: clang/include/clang/Basic/Cuda.h:108 +enum class CudaFeature { + CUDA_USES_NEW_LAUNCH, +}; Should this enum be documented?

[PATCH] D56411: [CUDA][HIP][Sema] Fix template kernel with function as template parameter

jlebar added a comment. __host__ void bar() {} __device__ int bar() { return 0; } __host__ __device__ void foo() { int x = bar(); } template __global__ void kernel() { devF();} kernel(); > we DTRT for this case. Here __host__ bar needs to return int since foo() > expects that.

[PATCH] D56411: [CUDA][HIP][Sema] Fix template kernel with function as template parameter

jlebar added a comment. Without reading the patch in detail (sorry) but looking mainly at the testcase: It looks like we're not checking how overloading and `__host__ __device__` functions play into this. Maybe there are some additional edge-cases to explore/check. Just some examples: Will

[PATCH] D56033: [CUDA] Treat extern global variable shadows same as regular extern vars.

jlebar accepted this revision. jlebar added inline comments. This revision is now accepted and ready to land. Comment at: clang/test/CodeGenCUDA/device-stub.cu:51 +// external device-side variables with definitiions should generate +// definitions for the shadows.

[PATCH] D51809: [CUDA][HIP] Fix ShouldDeleteSpecialMember for inherited constructors

jlebar accepted this revision. jlebar added inline comments. This revision is now accepted and ready to land. Comment at: lib/Sema/SemaDeclCXX.cpp:7231 +if (ICI) + CSM = getSpecialMember(MD); + LGTM, but perhaps we should use a new variable instead of

[PATCH] D51809: [CUDA][HIP] Fix assertion in LookupSpecialMember

jlebar requested changes to this revision. jlebar added subscribers: timshen, rsmith. jlebar added a comment. This revision now requires changes to proceed. Sorry for missing tra's ping earlier, I get a lot of HIP email traffic that's 99% inactionable by me, so I didn't notice my username in

[PATCH] D47757: [Sema] Produce diagnostics when unavailable aligned allocation/deallocation functions are called

jlebar added a comment. +tra in the hopes that perhaps he's comfortable reviewing this (sorry that I'm not). Repository: rC Clang https://reviews.llvm.org/D47757 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D49763: [CUDA] Call atexit() for CUDA destructor early on.

jlebar accepted this revision. jlebar added inline comments. This revision is now accepted and ready to land. Comment at: clang/lib/CodeGen/CGCUDANV.cpp:379 + // Create destructor and register it with atexit() the way NVCC does it. Doing + // it during regular destructor

[PATCH] D48037: [CUDA] Add tests to ensure that std::min/max can be called from __host__ __device__ functions.

This revision was automatically updated to reflect the committed changes. Closed by commit rL336029: [CUDA] Add tests to ensure that std::min/max can be called from __host__… (authored by jlebar, committed by ). Repository: rL LLVM https://reviews.llvm.org/D48037 Files:

[PATCH] D48152: [CUDA] Add tests that, in C++14 mode, min/max are constexpr.

This revision was automatically updated to reflect the committed changes. Closed by commit rL336030: [CUDA] Add tests that, in C++14 mode, min/max are constexpr. (authored by jlebar, committed by ). Repository: rL LLVM https://reviews.llvm.org/D48152 Files:

[PATCH] D48151: [CUDA] Make __host__/__device__ min/max overloads constexpr in C++14.

This revision was automatically updated to reflect the committed changes. Closed by commit rL336026: [CUDA] Make __host__/__device__ min/max overloads constexpr in C++14. (authored by jlebar, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit:

[PATCH] D48036: [CUDA] Make min/max shims host+device.

This revision was automatically updated to reflect the committed changes. Closed by commit rL336025: [CUDA] Make min/max shims host+device. (authored by jlebar, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit:

[PATCH] D48036: [CUDA] Make min/max shims host+device.

jlebar added a comment. > Looks right to me (other than the missing constexpr in C++14 onwards). Though > this is subtle enough that I suspect the only way to know for sure is to try > it. Thanks a lot, Richard. FTR the missing constexpr is in https://reviews.llvm.org/D48151.

[PATCH] D47757: [Sema] Produce diagnostics when unavailable aligned allocation/deallocation functions are called

jlebar added a comment. In https://reviews.llvm.org/D47757#1142886, @ahatanak wrote: > I mean ToT clang (without my patch applied) seems to select the non-sized > host version 'T::operator delete(void*)'. OK, if this is just making an error out of something which previously silently didn't

[PATCH] D47757: [Sema] Produce diagnostics when unavailable aligned allocation/deallocation functions are called

jlebar added a comment. > @jlebar, is the change I made to call-host-fn-from-device.cu correct? I don't think so -- that's a change in overloading behavior afaict. Repository: rC Clang https://reviews.llvm.org/D47757 ___ cfe-commits mailing

[PATCH] D48036: [CUDA] Make min/max shims host+device.

jlebar added a comment. @rsmith friendly ping on this one. https://reviews.llvm.org/D48036 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48151: [CUDA] Make __host__/__device__ min/max overloads constexpr in C++14.

jlebar added a comment. In https://reviews.llvm.org/D48151#1133954, @rsmith wrote: > LGTM Thank you for the review, Richard. Will check this in once the whole stack is ready -- just need https://reviews.llvm.org/D48036. https://reviews.llvm.org/D48151

[PATCH] D48151: [CUDA] Make __host__/__device__ min/max overloads constexpr in C++14.

jlebar added a comment. @rsmith friendly ping on this review. https://reviews.llvm.org/D48151 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48036: [CUDA] Make min/max shims host+device.

jlebar added a comment. @rsmith friendly ping on this one. https://reviews.llvm.org/D48036 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48036: [CUDA] Make min/max shims host+device.

jlebar added a comment. In https://reviews.llvm.org/D48036#1131279, @tra wrote: > Ack. Patches sent (see dependency chain in phab). https://reviews.llvm.org/D48036 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D48152: [CUDA] Add tests that, in C++14 mode, min/max are constexpr.

jlebar created this revision. jlebar added reviewers: rsmith, tra. Herald added a subscriber: llvm-commits. Repository: rT test-suite https://reviews.llvm.org/D48152 Files: External/CUDA/algorithm.cu Index: External/CUDA/algorithm.cu

[PATCH] D48151: [CUDA] Make __host__/__device__ min/max overloads constexpr in C++14.

jlebar created this revision. jlebar added reviewers: rsmith, tra. Herald added a subscriber: sanjoy. Tests in a separate change to the test-suite. https://reviews.llvm.org/D48151 Files: clang/lib/Headers/cuda_wrappers/algorithm Index: clang/lib/Headers/cuda_wrappers/algorithm

[PATCH] D48036: [CUDA] Make min/max shims host+device.

jlebar added a comment. > Last comment in the bug pointed out that those overloads should be constexpr > in c++14. Maybe in a separate patch, though. Yeah, would prefer to do it in a separate patch. It's possible that having constexpr min/max in C++14 mode *without a C++14 standard library*

[PATCH] D48037: [CUDA] Add tests to ensure that std::min/max can be called from __host__ __device__ functions.

jlebar created this revision. jlebar added a reviewer: rsmith. Herald added subscribers: llvm-commits, sanjoy. Tests for https://reviews.llvm.org/D48036 / PR37753. Repository: rT test-suite https://reviews.llvm.org/D48037 Files: External/CUDA/algorithm.cu Index:

[PATCH] D48036: [CUDA] Make min/max shims host+device.

jlebar created this revision. jlebar added a reviewer: rsmith. Herald added a subscriber: sanjoy. Fixes PR37753: min/max can't be called from __host__ __device__ functions in C++14 mode. Testcase in a separate test-suite commit. https://reviews.llvm.org/D48036 Files:

[PATCH] D47804: [CUDA] Replace 'nv_weak' attributes in CUDA headers with 'weak'.

jlebar accepted this revision. jlebar added a comment. This revision is now accepted and ready to land. What could possibly go wrong. https://reviews.llvm.org/D47804 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D47070: [CUDA] Upgrade linked bitcode to enable inlining

jlebar added a comment. I defer to Art on this one. Repository: rC Clang https://reviews.llvm.org/D47070 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46994: [test-suite] Test CUDA in C++14 mode with C++11 stdlibs.

This revision was automatically updated to reflect the committed changes. Closed by commit rL332659: [test-suite] Test CUDA in C++14 mode with C++11 stdlibs. (authored by jlebar, committed by ). Changed prior to commit: https://reviews.llvm.org/D46994?vs=147225=147383#toc Repository: rL

[PATCH] D46995: [test-suite] Enable CUDA complex tests with libc++ now that D25403 is resolved.

This revision was automatically updated to reflect the committed changes. jlebar marked an inline comment as done. Closed by commit rL332660: [test-suite] Enable CUDA complex tests with libc++ now that D25403 is resolved. (authored by jlebar, committed by ). Repository: rL LLVM

[PATCH] D46994: [test-suite] Test CUDA in C++14 mode with C++11 stdlibs.

jlebar marked an inline comment as done. jlebar added a comment. Thanks for the reviews, Art. Submitting with this change... Repository: rT test-suite https://reviews.llvm.org/D46994 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D46995: [test-suite] Enable CUDA complex tests with libc++ now that D25403 is resolved.

jlebar marked an inline comment as done. jlebar added inline comments. Comment at: External/CUDA/complex.cu:24 // libstdc++ (compile errors in ). -#if __cplusplus >= 201103L && !defined(_LIBCPP_VERSION) && \ -(__cplusplus < 201402L || STDLIB_VERSION >= 2014) +#if

[PATCH] D46782: [CUDA] Allow "extern __shared__ Foo foo[]" within anon. namespaces.

This revision was automatically updated to reflect the committed changes. Closed by commit rC332621: [CUDA] Allow extern __shared__ Foo foo[] within anon. namespaces. (authored by jlebar, committed by ). Herald added a subscriber: cfe-commits. Changed prior to commit:

  1   2   3   >