s-perron wrote:
Failure is unrelated to my change.
https://github.com/llvm/llvm-project/pull/121961
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2158,6 +2158,10 @@ enum CXCursorKind {
*/
CXCursor_OMPAssumeDirective = 309,
+ /** OpenMP assume directive.
+ */
+ CXCursor_OMPStripeDirective = 310,
kparzysz wrote:
Please add this to `clang/bindings/python/clang/cindex.py` as well.
https://git
https://github.com/ronlieb approved this pull request.
https://github.com/llvm/llvm-project/pull/121663
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -839,6 +839,12 @@ def BuiltinAssumeAligned : Builtin {
let Prototype = "void*(void const*, size_t, ...)";
}
+def BuiltinAssumeDereferenceable : Builtin {
+ let Spellings = ["__builtin_assume_dereferenceable"];
+ let Attributes = [NoThrow, Const, Constexpr];
@@ -15978,6 +15988,24 @@ Decl *Sema::ActOnFinishFunctionBody(Decl *dcl, Stmt
*Body,
CheckCoroutineWrapper(FD);
}
+ // Diagnose invalid SYCL kernel entry point function declarations.
+ if (FD && !FD->isInvalidDecl() && !FD->isTemplated() &&
tahonerma
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Joseph Huber (jhuber6)
Changes
Summary:
Currently we prevent the following from working. However, it is
completely reasonable to be able to target the files individually.
```
$ clang --target=amdgcn-amd-amdhsa -fopenmp
```
This patch lifts
@@ -206,3 +208,124 @@ void SemaSYCL::handleKernelEntryPointAttr(Decl *D, const
ParsedAttr &AL) {
D->addAttr(::new (SemaRef.Context)
SYCLKernelEntryPointAttr(SemaRef.Context, AL, TSI));
}
+
+static SourceLocation SourceLocationForType(QualType QT) {
+ Source
https://github.com/petrhosek approved this pull request.
https://github.com/llvm/llvm-project/pull/121875
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
compnerd wrote:
(waiting to see if Aaron can also take a look)
https://github.com/llvm/llvm-project/pull/119403
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexey-bataev wrote:
Maybe just turn on OpenMPIsTargetDevice if `gpu target + -fopenmp` is specified?
https://github.com/llvm/llvm-project/pull/122149
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
jhuber6 wrote:
> Maybe just turn on OpenMPIsTargetDevice if `gpu target + -fopenmp` is
> specified?
I'll give it a try.
https://github.com/llvm/llvm-project/pull/122149
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
shiltian wrote:
What code generation path would be used in this case? The GPU code generation
or regular host OpenMP?
https://github.com/llvm/llvm-project/pull/122149
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
@@ -1154,3 +1154,56 @@
// RUN: not %clang --target=x86_64-linux-gnu -fsanitize=realtime,undefined %s
-### 2>&1 | FileCheck %s --check-prefix=CHECK-REALTIME-UBSAN
// CHECK-REALTIME-UBSAN: error: invalid argument '-fsanitize=realtime' not
allowed with '-fsanitize=undefined'
+
jhuber6 wrote:
> What code generation path would be used in this case? The GPU code generation
> or regular host OpenMP?
The GPU path, I'm treating that as the code generation path that created
correct runtime code for the GPU. I.e. you can link it with your OpenMP
offloading program and it'l
https://github.com/jroelofs approved this pull request.
https://github.com/llvm/llvm-project/pull/122145
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> > In practice, when compiling C for Windows/ARMv7, NEON actually still is
> > available, but not when compiling assembly files.
>
> So the "bug" if we're going to call it that, is that C code can produce Neon
> but assembly files compiled in the same way cannot use Neon instr
@@ -83,6 +84,7 @@ const LangASMap AMDGPUTargetInfo::AMDGPUDefIsPrivMap = {
llvm::AMDGPUAS::FLAT_ADDRESS, // ptr32_uptr
llvm::AMDGPUAS::FLAT_ADDRESS, // ptr64
llvm::AMDGPUAS::FLAT_ADDRESS, // hlsl_groupshared
+llvm::AMDGPUAS::FLAT_ADDRESS, // hlsl_private
---
Author: Jan Voung
Date: 2025-01-08T08:27:16-05:00
New Revision: 72a28a3bf0b539bcdfd8f41905675ce6a890c0ac
URL:
https://github.com/llvm/llvm-project/commit/72a28a3bf0b539bcdfd8f41905675ce6a890c0ac
DIFF:
https://github.com/llvm/llvm-project/commit/72a28a3bf0b539bcdfd8f41905675ce6a890c0ac.diff
LOG
https://github.com/jvoung closed
https://github.com/llvm/llvm-project/pull/120249
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidSpickett wrote:
> In practice, when compiling C for Windows/ARMv7, NEON actually still is
> available, but not when compiling assembly files.
So the "bug" if we're going to call it that, is that C code can produce Neon
but assembly files compiled in the same way cannot use Neon instructi
DavidSpickett wrote:
Or is it that this change allows other downstreams to patch the Linux issue in
a way that does not break Windows and iOS in the process?
If I'm using clang on Debian, that's where I would find this C can use Neon but
assembly cannot problem.
https://github.com/llvm/llvm-p
mstorsjo wrote:
> Or is it that this change allows other downstreams to patch the Linux issue
> in a way that does not break Windows and iOS in the process?
Exactly - this makes it more explicit upstream, to make it easier to tweak for
downstreams for Linux targets, without breaking the other
zmodem wrote:
> We've started seeing libc++ test failures in the Fuchsia toolchain buildbots
> for Windows
We're hitting the same error in Chromium builds. Here is a stand-alone
reproducer: https://crbug.com/388428503#comment4
https://github.com/llvm/llvm-project/pull/102857
https://github.com/zahiraam edited
https://github.com/llvm/llvm-project/pull/122108
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zahiraam edited
https://github.com/llvm/llvm-project/pull/122108
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Setting default features for a platform based on what we happened to choose
> (likely with a very thin justification) to be the default CPU sounds fragile
> to me, so I think this patch is a good step forward. Even if there weren't
> this downstream patch interacting with it,
@@ -83,6 +84,7 @@ const LangASMap AMDGPUTargetInfo::AMDGPUDefIsPrivMap = {
llvm::AMDGPUAS::FLAT_ADDRESS, // ptr32_uptr
llvm::AMDGPUAS::FLAT_ADDRESS, // ptr64
llvm::AMDGPUAS::FLAT_ADDRESS, // hlsl_groupshared
+llvm::AMDGPUAS::FLAT_ADDRESS, // hlsl_private
---
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff b054289882145f5a1aa8e1d6538ac4714df17059
6be06e0d53c365479ef813b2a7057a3591a1c457 --e
https://github.com/s-perron closed
https://github.com/llvm/llvm-project/pull/121963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7559,6 +7559,26 @@ The attributes ``__arm_in(S)``, ``__arm_out(S)``,
``__arm_inout(S)`` and
}];
}
+def ArmAgnosticDocs : Documentation {
+ let Category = DocCatArmSmeAttributes;
+ let Content = [{
+The ``__arm_agnostic`` keyword applies to prototyped function types an
https://github.com/kiranchandramohan created
https://github.com/llvm/llvm-project/pull/122144
…ariables
Patch adds a flag to control zero initialization of global variables without
default initialization. The default is to zero initialize.
>From c4ecdf68662329811e22e4a471c393ea5981785a Mon Se
@@ -1818,8 +1819,21 @@ void Preprocessor::ExpandBuiltinMacro(Token &Tok) {
// usual allocation and deallocation functions. Required by libc++
return 201802;
default:
+// We may get here because of aux builtins which may not be
+
https://github.com/sarnex edited
https://github.com/llvm/llvm-project/pull/121839
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Kiran Chandramohan (kiranchandramohan)
Changes
…ariables
Patch adds a flag to control zero initialization of global variables without
default initialization. The default is to zero initialize.
---
Full diff: https://github.com/llvm/llvm-
https://github.com/kmclaughlin-arm updated
https://github.com/llvm/llvm-project/pull/121777
>From 00772b871de43a5e30aca2a65a89675117cafbf1 Mon Sep 17 00:00:00 2001
From: Kerry McLaughlin
Date: Tue, 31 Dec 2024 17:22:02 +
Subject: [PATCH 1/4] [AArch64][SME] Add diagnostics to
CheckConstexpr
ian-twilightcoder wrote:
> > LLVM Buildbot has detected a new failure on builder `fuchsia-x86_64-linux`
> > running on `fuchsia-debian-64-us-central1-a-1` while building `clang,llvm`
> > at step 4 "annotate".
> > Full details are available at:
> > https://lab.llvm.org/buildbot/#/builders/11/bu
llvmbot wrote:
@llvm/pr-subscribers-flang-driver
@llvm/pr-subscribers-clang-driver
Author: Kiran Chandramohan (kiranchandramohan)
Changes
…ariables
Patch adds a flag to control zero initialization of global variables without
default initialization. The default is to zero initialize.
---
https://github.com/ian-twilightcoder created
https://github.com/llvm/llvm-project/pull/122145
Split darwin-embedded-search-paths.c into two tests for the different values of
CLANG_DEFAULT_CXX_STDLIB.
>From 67d75753b9d03973374e278de0ce55b537f370f2 Mon Sep 17 00:00:00 2001
From: Ian Anderson
Da
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/122029
>From 1824674744d6fba1dd74c74d54aae9b603d8b854 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Wed, 8 Jan 2025 00:24:09 +
Subject: [PATCH 1/2] Use range-based for to iterate over fields in record
layout, NFC
https://github.com/cor3ntin closed
https://github.com/llvm/llvm-project/pull/122130
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
philnik777 wrote:
Does this mean we should avoid `__builtin_constant_p` during constant
evaluation when possible and instead add custom builtins in the few places we
actually need the correct answer during constant evaluation?
We currently use `__builtin_constant_p` in two different cases:
- W
Prabhuk wrote:
@RossComputerGuy FYI
https://github.com/llvm/llvm-project/pull/121875
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ian-twilightcoder updated
https://github.com/llvm/llvm-project/pull/122145
>From c37b6e3e59f024f2070b740fb91f7ad3298a61e4 Mon Sep 17 00:00:00 2001
From: Ian Anderson
Date: Wed, 8 Jan 2025 09:35:04 -0800
Subject: [PATCH] [test][Driver][clang] Fix darwin-embedded-search-paths.c
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
@llvm/pr-subscribers-clang
Author: Ian Anderson (ian-twilightcoder)
Changes
Split darwin-embedded-search-paths.c into two tests for the different values of
CLANG_DEFAULT_CXX_STDLIB.
---
Full diff: https://github.com/llvm/llvm-project/pull/
ian-twilightcoder wrote:
Does anyone know a cleaner way of testing this besides just duplicating the
test?
https://github.com/llvm/llvm-project/pull/122145
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/122029
>From 1824674744d6fba1dd74c74d54aae9b603d8b854 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Wed, 8 Jan 2025 00:24:09 +
Subject: [PATCH 1/3] Use range-based for to iterate over fields in record
layout, NFC
@@ -1,3 +1,4 @@
+// REQUIRES: default-cxx-stdlib=libstdc++
ian-twilightcoder wrote:
Maybe this should be `!=libc++` instead?
https://github.com/llvm/llvm-project/pull/122145
___
cfe-commits mailing list
cfe-commits@lis
@@ -1818,8 +1819,21 @@ void Preprocessor::ExpandBuiltinMacro(Token &Tok) {
// usual allocation and deallocation functions. Required by libc++
return 201802;
default:
+// We may get here because of aux builtins which may not be
+
@@ -3178,98 +3178,74 @@ bool
SPIRVInstructionSelector::selectFirstBitSet64Overflow(
Register ResVReg, const SPIRVType *ResType, MachineInstr &I,
Register SrcReg, unsigned BitSetOpcode, bool SwapPrimarySide) const {
+ // SPIR-V only allow vecs of size 2,3,4. Calling w
erichkeane wrote:
> I am afraid this will break all existing CUDA/HIP programs since they expect
> to be able to parse the builtins for both host and device targets.
>
> In the spirit of single source, the compiler sees the entire code for all
> targets, including host target and all device ta
balazske wrote:
Our plan is to add a new check for dereference of fixed address (like `(*0x111)
= 1`). This is similar to the current `FixedAddressChecker` but has less false
positives (if a fixed value is used as placeholder but never dereferenced).
Additionally the existing checks for undefi
jhuber6 wrote:
> I am afraid this will break all existing CUDA/HIP programs since they expect
> to be able to parse the builtins for both host and device targets.
>
> In the spirit of single source, the compiler sees the entire code for all
> targets, including host target and all device targe
jhuber6 wrote:
> This is/was my concern. However, upon thinking further, as long as we
> RECOGNIZE/Parse/etc the builtins, it is OK I think if we report
> "!__has_builtin".
>
> That is:
>
> ```
> void foo() {
> #if __has_builtin(__builtin_x86_thing)
> __builtin_x86_thing();
> #else
> __builti
https://github.com/maflcko created
https://github.com/llvm/llvm-project/pull/122141
Fixes https://github.com/llvm/llvm-project/issues/122096
>From 92e175391c150d53f887e24125a7f80c26fc630e Mon Sep 17 00:00:00 2001
From: MarcoFalke <*~=`'#}+{/-|&$^_...@721217.xyz>
Date: Wed, 8 Jan 2025 17:46:47 +
llvmbot wrote:
@llvm/pr-subscribers-clang-tidy
Author: None (maflcko)
Changes
Fixes https://github.com/llvm/llvm-project/issues/122096
---
Full diff: https://github.com/llvm/llvm-project/pull/122141.diff
3 Files Affected:
- (modified) clang-tools-extra/clang-tidy/misc/UseInternalLinkag
llvmbot wrote:
@llvm/pr-subscribers-clang-static-analyzer-1
Author: Balázs Kéri (balazske)
Changes
The checker currently reports beneath the null dereference dereferences of
undefined value and of label addresses. If we want to add more kinds of invalid
dereferences (or split the existin
https://github.com/balazske created
https://github.com/llvm/llvm-project/pull/122139
The checker currently reports beneath the null dereference dereferences of
undefined value and of label addresses. If we want to add more kinds of invalid
dereferences (or split the existing functionality) it
@@ -3178,98 +3178,74 @@ bool
SPIRVInstructionSelector::selectFirstBitSet64Overflow(
Register ResVReg, const SPIRVType *ResType, MachineInstr &I,
Register SrcReg, unsigned BitSetOpcode, bool SwapPrimarySide) const {
+ // SPIR-V only allow vecs of size 2,3,4. Calling w
@@ -3178,98 +3178,74 @@ bool
SPIRVInstructionSelector::selectFirstBitSet64Overflow(
Register ResVReg, const SPIRVType *ResType, MachineInstr &I,
Register SrcReg, unsigned BitSetOpcode, bool SwapPrimarySide) const {
+ // SPIR-V only allow vecs of size 2,3,4. Calling w
@@ -3178,98 +3178,74 @@ bool
SPIRVInstructionSelector::selectFirstBitSet64Overflow(
Register ResVReg, const SPIRVType *ResType, MachineInstr &I,
Register SrcReg, unsigned BitSetOpcode, bool SwapPrimarySide) const {
+ // SPIR-V only allow vecs of size 2,3,4. Calling w
@@ -3178,98 +3178,74 @@ bool
SPIRVInstructionSelector::selectFirstBitSet64Overflow(
Register ResVReg, const SPIRVType *ResType, MachineInstr &I,
Register SrcReg, unsigned BitSetOpcode, bool SwapPrimarySide) const {
+ // SPIR-V only allow vecs of size 2,3,4. Calling w
yxsamliu wrote:
I am afraid this will break all existing CUDA/HIP programs since they expect to
be able to parse the builtins for both host and device targets.
In the spirit of single source, the compiler sees the entire code for all
targets, including host target and all device targets. It is
balazske wrote:
I wanted to avoid change the current behavior of `core.NullDereference`. But it
is better to move the option of address space suppression into the modeling
part, I guess this option should be used for all types of invalid dereferences.
https://github.com/llvm/llvm-project/pull/
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 6414d6174198689f00ff325e667fff9eb1c0d9de
135839a993f1cad32d65d21c6aeaef6f074a1997 --e
@@ -8010,15 +8010,19 @@ void Clang::ConstructJob(Compilation &C, const
JobAction &JA,
}
}
- if (Args.hasArg(options::OPT_forder_file_instrumentation)) {
- CmdArgs.push_back("-forder-file-instrumentation");
- // Enable order file instrumentation when ThinLTO is
@@ -8265,6 +8265,11 @@ def internal_externc_isystem : Separate<["-"],
"internal-externc-isystem">,
"implicit extern \"C\" semantics; these are assumed to not be "
"user-provided and are used to model system and standard headers' "
"paths.">;
+d
https://github.com/tahonermann updated
https://github.com/llvm/llvm-project/pull/120327
>From 6ed96d3bf22c5da5af995ea5ffe083baf91594bb Mon Sep 17 00:00:00 2001
From: Tom Honermann
Date: Fri, 1 Nov 2024 16:03:24 -0700
Subject: [PATCH 1/9] [SYCL] Basic diagnostics for the sycl_kernel_entry_point
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
@llvm/pr-subscribers-clang
Author: Florian Hahn (fhahn)
Changes
While there are no special rules in the standards regarding void pointers and
strict aliasing, emitting distinct tags for void pointers break some common
idioms and there is
@@ -1468,9 +1468,14 @@ Compilation *Driver::BuildCompilation(ArrayRef ArgList) {
// Set specific Vulkan version if applicable.
if (const Arg *A = Args.getLastArg(options::OPT_fspv_target_env_EQ)) {
- const llvm::StringSet<> ValidValues = {"vulkan1.2",
@@ -8207,6 +8207,14 @@ ExprResult InitializationSequence::Perform(Sema &S,
Kind.getRange().getEnd());
} else {
CurInit = new (S.Context) ImplicitValueInitExpr(Step->Type);
+// Note the return value isn't used to return early
+// to pres
zyn0217 wrote:
I see the problem here:
When substituting into the constraint __is_derived_from_optional with [_Tp =
__sfinae_assign_base] prior to substituting the three-way operator, we must
also substitute into the lambda call expression. This requires instantiating
the lambda body to deduc
@@ -1468,9 +1468,14 @@ Compilation *Driver::BuildCompilation(ArrayRef ArgList) {
// Set specific Vulkan version if applicable.
if (const Arg *A = Args.getLastArg(options::OPT_fspv_target_env_EQ)) {
- const llvm::StringSet<> ValidValues = {"vulkan1.2",
@@ -8265,6 +8265,11 @@ def internal_externc_isystem : Separate<["-"],
"internal-externc-isystem">,
"implicit extern \"C\" semantics; these are assumed to not be "
"user-provided and are used to model system and standard headers' "
"paths.">;
+d
@@ -4174,7 +4174,7 @@ bool CompilerInvocation::ParseLangArgs(LangOptions &Opts,
ArgList &Args,
}
// Check if -fopenmp is specified and set default version to 5.0.
- Opts.OpenMP = Args.hasArg(OPT_fopenmp) ? 51 : 0;
+ Opts.OpenMP = Args.hasArg(OPT_fopenmp) ? 60 : 0;
-
https://github.com/qt-tatiana created
https://github.com/llvm/llvm-project/pull/122127
- add an option ``QtEnabled``, that makes C++17 ``q20::cmp_*`` alternative
available for Qt-based applications.
>From b870cef0f9e5c62e5dd760a9fc324613b3cc783a Mon Sep 17 00:00:00 2001
From: Tatiana Borisova
MichelleCDjunaidi wrote:
Working on it.
https://github.com/llvm/llvm-project/pull/102299
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/saiislam requested changes to this pull request.
I agree with both points raised by @mjklemm .
Even when we make 6.0 as default, I am pretty sure that many more LIT tests
need to be updated. Please see https://reviews.llvm.org/D129635 for last update
exercise.
We also will
cor3ntin wrote:
@zyn0217 Ouch. Lets revert and try to figure that out... @erichkeane
https://github.com/llvm/llvm-project/pull/102857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zyn0217 created
https://github.com/llvm/llvm-project/pull/122130
Unfortunately that breaks some code on Windows when lambdas come into play, as
reported in
https://github.com/llvm/llvm-project/pull/102857#issuecomment-2577861178
This reverts commit 96eced624e0f120155256033f
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Younan Zhang (zyn0217)
Changes
Unfortunately that breaks some code on Windows when lambdas come into play, as
reported in
https://github.com/llvm/llvm-project/pull/102857#issuecomment-2577861178
This reverts commit 96eced624e0f1201552560
@@ -1309,6 +1309,16 @@ Sema::CheckOverload(Scope *S, FunctionDecl *New, const
LookupResult &Old,
return Ovl_Overload;
}
+template static bool hasExplicitAttr(const FunctionDecl *D) {
+ if (!D)
+return false;
yxsamliu wrote:
will do
https://github.co
zyn0217 wrote:
Reverted in https://github.com/llvm/llvm-project/pull/122130
https://github.com/llvm/llvm-project/pull/102857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Keenuts approved this pull request.
https://github.com/llvm/llvm-project/pull/121961
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -15978,6 +15988,24 @@ Decl *Sema::ActOnFinishFunctionBody(Decl *dcl, Stmt
*Body,
CheckCoroutineWrapper(FD);
}
+ // Diagnose invalid SYCL kernel entry point function declarations.
+ if (FD && !FD->isInvalidDecl() && !FD->isTemplated() &&
+ FD->hasAttr()) {
+
@@ -1550,6 +1550,8 @@ NamedDecl *Sema::ActOnNonTypeTemplateParameter(Scope *S,
Declarator &D,
IdResolver.AddDecl(Param);
}
+ ProcessDeclAttributes(S, Param, D);
AaronBallman wrote:
We definitely need some changes because we drop the attributes on the
https://github.com/llvm-beanz approved this pull request.
https://github.com/llvm/llvm-project/pull/122157
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> Maybe just turn on OpenMPIsTargetDevice if `gpu target + -fopenmp` is
> specified?
Doesn't work, it causes all definitions to be stripped as they are not declared
on the device, which is not what we want.
https://github.com/llvm/llvm-project/pull/122149
__
shiltian wrote:
I think that is a misuse of OpenMP semantics. We can't expect to have regular
OpenMP code working in the same way as OpenMP offloading code when targeting a
GPU meanwhile while the code is not wrapped into `target` region. I understand
to have variants and declare target is not
shiltian wrote:
> It should maintain the normal semantics you'd get with -fopenmp except it
> codegens certain things differently.
That is the key difference.
> Alternatively I could just remove OpenMP entirely from the DeviceRTL so I
> might just do that instead.
+1
https://github.com/llvm
efriedma-quic wrote:
> However what we want to achieve with this is to make the state of the
> streaming mode known to potentially inlineable called functions, allowing for
> further inlining and identification/removal of dead code
It seems like we're in agreement that the llvm.assume doesn't
https://github.com/petrhosek approved this pull request.
https://github.com/llvm/llvm-project/pull/119403
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM but I added our cmake code owners just in case they have the bandwidth to
also double-check, since I got this wrong before. :-)
https://github.com/llvm/llvm-project/pull/119403
___
cfe-c
@@ -8010,15 +8010,19 @@ void Clang::ConstructJob(Compilation &C, const
JobAction &JA,
}
}
- if (Args.hasArg(options::OPT_forder_file_instrumentation)) {
- CmdArgs.push_back("-forder-file-instrumentation");
- // Enable order file instrumentation when ThinLTO is
https://github.com/inbelic converted_to_draft
https://github.com/llvm/llvm-project/pull/121799
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -29,6 +29,12 @@ static constexpr StringRef DefaultIncludeTypeRegex =
AST_MATCHER(VarDecl, isLocalVarDecl) { return Node.isLocalVarDecl(); }
AST_MATCHER(VarDecl, isReferenced) { return Node.isReferenced(); }
+AST_MATCHER_P(VarDecl, explicitMarkUnused, LangOptions, LangOpts)
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Craig Topper (topperc)
Changes
This is the CPU in SiFive's HiFive Premier P550 development board.
Scheduler model will come in a later patch.
---
Full diff: https://github.com/llvm/llvm-project/pull/122164.diff
4 Files Affected:
https://github.com/topperc created
https://github.com/llvm/llvm-project/pull/122164
This is the CPU in SiFive's HiFive Premier P550 development board.
Scheduler model will come in a later patch.
>From 207face06fbb98c811aefd4d541e62d88f13f4bd Mon Sep 17 00:00:00 2001
From: Craig Topper
Date: W
https://github.com/ian-twilightcoder updated
https://github.com/llvm/llvm-project/pull/122145
>From 4bd9ce309935451900d7ebc13a111bedf91d12d0 Mon Sep 17 00:00:00 2001
From: Ian Anderson
Date: Wed, 8 Jan 2025 09:35:04 -0800
Subject: [PATCH] [test][Driver][clang] Fix darwin-embedded-search-paths.c
https://github.com/fahadnayyar created
https://github.com/llvm/llvm-project/pull/122167
Adding test case to verify that SwiftReturnOwnership works correctly for ObjC
functions and methods as well.
rdar://142504115
>From 3c8fc5525710cb3bed6e6b4035e5d62693d90ade Mon Sep 17 00:00:00 2001
From: F
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (fahadnayyar)
Changes
Adding test case to verify that SwiftReturnOwnership works correctly for ObjC
functions and methods as well.
rdar://142504115
---
Full diff: https://github.com/llvm/llvm-project/pull/122167.diff
4 Files Affec
301 - 400 of 545 matches
Mail list logo
