https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/96573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Richard Smith
Date: 2024-06-25T23:51:12-07:00
New Revision: 569faa4dc04cf6849057e56ef07b56ad27f6ef9e
URL:
https://github.com/llvm/llvm-project/commit/569faa4dc04cf6849057e56ef07b56ad27f6ef9e
DIFF:
https://github.com/llvm/llvm-project/commit/569faa4dc04cf6849057e56ef07b56ad27f6ef9e.diff
zygoloid wrote:
> I have a question about the "sub-object" part. Do we attempt to discover the
> sub-object past any casting?
Good question. I'm going to merge this PR, so I've filed #96737 for this
ongoing discussion.
https://github.com/llvm/llvm-project/pull/96573
__
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
@llvm/pr-subscribers-clang
Author: Petr Hosek (petrhosek)
Changes
We want to support using a complete Clang/LLVM toolchain that includes LLVM
libc and libc++ for baremetal targets. To do so, we need the driver to add the
necessary include
https://github.com/petrhosek created
https://github.com/llvm/llvm-project/pull/96736
We want to support using a complete Clang/LLVM toolchain that includes LLVM
libc and libc++ for baremetal targets. To do so, we need the driver to add the
necessary include paths.
>From db5ae584cc00717d667d42
@@ -707,7 +707,39 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee = CGCallee::forDirect(calle
https://github.com/vfdff updated https://github.com/llvm/llvm-project/pull/96025
>From ed6292fd0e9119322c39e5f37e2225c76e324101 Mon Sep 17 00:00:00 2001
From: zhongyunde 00443407
Date: Tue, 18 Jun 2024 09:21:07 -0400
Subject: [PATCH 1/5] [TBAA] Emit int TBAA metadata on FP math libcalls
Base on
@@ -2986,6 +2989,9 @@ void
MicrosoftCXXNameMangler::mangleCallingConvention(CallingConv CC) {
case CC_Swift: Out << 'S'; break;
antangelo wrote:
Done
https://github.com/llvm/llvm-project/pull/96487
___
cfe-commit
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,7 @@
+// RUN: mlir-translate -mlir-to-llvmir %s | FileCheck %s
gysit wrote:
This may require x86-registered-target as well?
https://github.com/llvm/llvm-project/pull/96688
___
cfe-commits mailing list
cfe-co
@@ -0,0 +1,9 @@
+; RUN: mlir-translate -import-llvm -split-input-file %s | FileCheck %s
gysit wrote:
Should this test also be guarded with `REQUIRES: x86-registered-target`?
https://github.com/llvm/llvm-project/pull/96688
Author: Chuanqi Xu
Date: 2024-06-26T13:25:06+08:00
New Revision: 2ee2b6aa7a3d9ba6ba13f6881b25e26d7d12c823
URL:
https://github.com/llvm/llvm-project/commit/2ee2b6aa7a3d9ba6ba13f6881b25e26d7d12c823
DIFF:
https://github.com/llvm/llvm-project/commit/2ee2b6aa7a3d9ba6ba13f6881b25e26d7d12c823.diff
LO
https://github.com/wzssyqa updated
https://github.com/llvm/llvm-project/pull/96281
>From 1f357abed9d9e304b12ddd05a525557a8b0082c6 Mon Sep 17 00:00:00 2001
From: YunQiang Su
Date: Fri, 21 Jun 2024 14:28:42 +0800
Subject: [PATCH 1/2] Clang: Support minimumnum and maximumnum intrinsics
We just in
https://github.com/antangelo updated
https://github.com/llvm/llvm-project/pull/96487
>From 1e95098e324860268d55e72a14090f9524c7dde1 Mon Sep 17 00:00:00 2001
From: Antonio Abbatangelo
Date: Mon, 24 Jun 2024 09:49:28 -0400
Subject: [PATCH 1/2] [MS ABI]: Support preserve_none in MS ABI
---
clang
zyn0217 wrote:
> +1 to get this added to 18.1.9 if there ever is one - especially if the
> Android NDK moves to it - the 27 betas fail for me too
Sorry, I was unaware we had a scheduled release of 18.1.8 last week.
@tstellar @cor3ntin do you think this is worth another 18.x release (presumably
trcrsired wrote:
@MaskRay
https://github.com/llvm/llvm-project/pull/96417
___
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: None (martinboehme)
Changes
We were previously treating the operand of `typeid()` as being definitely
unevaluated, but it can be evaluated if it is a glvalue of polymorphic type.
This patch includes a test that fails without the fix.
---
https://github.com/martinboehme created
https://github.com/llvm/llvm-project/pull/96731
We were previously treating the operand of `typeid()` as being definitely
unevaluated, but it can be evaluated if it is a glvalue of polymorphic type.
This patch includes a test that fails without the fix.
https://github.com/h-vetinari updated
https://github.com/llvm/llvm-project/pull/93429
>From 8c1b899aa174b107fece1edbf99eaf261bdea516 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Mon, 25 Apr 2022 09:45:22 +0300
Subject: [PATCH 1/4] [runtimes] [CMake] Use CMAKE_REQUIRED_
efriedma-quic wrote:
If you want to push this forward, start a Discourse thread (discourse.llvm.org)
with a writeup of the proposal. Including an expanded rationale for why we
want this.
See also https://clang.llvm.org/get_involved.html
https://github.com/llvm/llvm-project/pull/92499
___
h-vetinari wrote:
I think that was the last one. :)
https://github.com/llvm/llvm-project/pull/96171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I don't think I like this approach:
- This seems like an easy way to unintentionally pass state between different
compilations.
- It seems very easy to try to use this API during LTO, and have it do nothing.
- I'm pretty sure this breaks existing workflows involving
AMDGPU
yamt wrote:
> If we're going to do this, it should probably also work for constants.
>
> Also, I think I'd prefer to sort out the situation with the C++ standard's
> rules for constant merging before we start extending those rules. See #63628.
may i update this to cover constants as well?
or,
https://github.com/vikramRH closed
https://github.com/llvm/llvm-project/pull/92725
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,29 @@
+USE_XMM=
phoebewang wrote:
How about we move these old implementations in to a seperate file (or leave
them where they are if you like) and rename them to _dept, so that we don't
rely on old compilers? We can then remove them as well as th
https://github.com/pcc closed https://github.com/llvm/llvm-project/pull/96721
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: pcc
Date: 2024-06-25T20:39:18-07:00
New Revision: 89d8df12015ac3440190d372a8d439614027dc2c
URL:
https://github.com/llvm/llvm-project/commit/89d8df12015ac3440190d372a8d439614027dc2c
DIFF:
https://github.com/llvm/llvm-project/commit/89d8df12015ac3440190d372a8d439614027dc2c.diff
LOG: Code
@@ -327,6 +327,26 @@ class LLVMContext {
[[deprecated("Always returns false")]]
bool supportsTypedPointers() const;
+ /// Get the current "default" target CPU (target-cpu function attribute). The
+ /// intent is that compiler frontends will set this to a value that refle
@@ -0,0 +1,17 @@
+// RUN: %clang -S -emit-llvm --coverage --target=aarch64-linux-android30
-fsanitize=hwaddress %s -o %t
pcc wrote:
Done
https://github.com/llvm/llvm-project/pull/96721
___
cfe-commits mailing list
cfe
@@ -21,10 +21,29 @@ typedef int __v2si __attribute__((__vector_size__(8)));
typedef short __v4hi __attribute__((__vector_size__(8)));
typedef char __v8qi __attribute__((__vector_size__(8)));
+/* Unsigned types */
+typedef unsigned long long __v1du __attribute__ ((__vector_size
https://github.com/pcc updated https://github.com/llvm/llvm-project/pull/96721
>From 14e72c19daefd09b6cfe7e99865b89afa8c5a4d8 Mon Sep 17 00:00:00 2001
From: Peter Collingbourne
Date: Tue, 25 Jun 2024 19:16:01 -0700
Subject: [PATCH 1/2] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
=?U
https://github.com/trcrsired updated
https://github.com/llvm/llvm-project/pull/96417
>From c776e704294a0fc0db478aab9a6a15d8a39202f6 Mon Sep 17 00:00:00 2001
From: trcrsired
Date: Sun, 23 Jun 2024 00:07:19 -0400
Subject: [PATCH] Support --sysroot= for ${arch}-windows-msvc targets
I think it is
ahmedbougacha wrote:
>> Do we want a lot of -fptrauth-xxx instead of -fptrauth-something=xxx,yyy,zzz?
>
> I would lean towards a single flag.
Comma-separated flags generally seem less user-friendly (for, e.g., grepping,
modifying, reading). To some extent we can mitigate that with the obvious
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/96084
>From 23844cd8b8fad07bce0c34f58430322090c5a793 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Wed, 19 Jun 2024 23:25:13 +0800
Subject: [PATCH 1/8] [Clang] Add diagnostic notes for implcitly generated
deductio
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/96084
>From 23844cd8b8fad07bce0c34f58430322090c5a793 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Wed, 19 Jun 2024 23:25:13 +0800
Subject: [PATCH 1/7] [Clang] Add diagnostic notes for implcitly generated
deductio
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/96084
>From 23844cd8b8fad07bce0c34f58430322090c5a793 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Wed, 19 Jun 2024 23:25:13 +0800
Subject: [PATCH 1/6] [Clang] Add diagnostic notes for implcitly generated
deductio
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
@@ -229,6 +229,10 @@ C++20 Feature Support
will now work.
(#GH62925).
+- Clang refactored the BMI format to make it possible to support no transitive
changes
ChuanqiXu9 wrote:
Good suggestions. Applied. (Just change `should` to `can`. Since I feel
`shou
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/96453
>From a035ae25314f3168f73108988f2bb7671e7d9e7f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Mon, 24 Jun 2024 11:41:23 +0800
Subject: [PATCH 1/2] [Doc] Update documentation for no-transitive-change
---
cla
https://github.com/h-vetinari updated
https://github.com/llvm/llvm-project/pull/96171
>From 1df587efeb71fb1929667f008d7e9b251863d9d8 Mon Sep 17 00:00:00 2001
From: "H. Vetinari"
Date: Thu, 20 Jun 2024 21:43:31 +1100
Subject: [PATCH 1/4] [cmake] switch to CMake's native check_linker_flag,
delet
https://github.com/h-vetinari updated
https://github.com/llvm/llvm-project/pull/93429
>From 8c1b899aa174b107fece1edbf99eaf261bdea516 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Mon, 25 Apr 2022 09:45:22 +0300
Subject: [PATCH 1/3] [runtimes] [CMake] Use CMAKE_REQUIRED_
https://github.com/h-vetinari updated
https://github.com/llvm/llvm-project/pull/93429
>From 8c1b899aa174b107fece1edbf99eaf261bdea516 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Mon, 25 Apr 2022 09:45:22 +0300
Subject: [PATCH 1/3] [runtimes] [CMake] Use CMAKE_REQUIRED_
@@ -327,6 +327,26 @@ class LLVMContext {
[[deprecated("Always returns false")]]
bool supportsTypedPointers() const;
+ /// Get the current "default" target CPU (target-cpu function attribute). The
+ /// intent is that compiler frontends will set this to a value that refle
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/96721
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/96721
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,17 @@
+// RUN: %clang -S -emit-llvm --coverage --target=aarch64-linux-android30
-fsanitize=hwaddress %s -o %t
MaskRay wrote:
Prefer %clang_cc1 in non-driver tests
https://github.com/llvm/llvm-project/pull/96721
___
llvmbot wrote:
@llvm/pr-subscribers-llvm-ir
Author: None (pcc)
Changes
Functions created with createWithDefaultAttr() need to have the
correct target-{cpu,features} attributes to avoid miscompilations
such as using the wrong relocation type to access globals (missing
tagged-globals feature
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (pcc)
Changes
Functions created with createWithDefaultAttr() need to have the
correct target-{cpu,features} attributes to avoid miscompilations
such as using the wrong relocation type to access globals (missing
tagged-globals feature),
https://github.com/pcc created https://github.com/llvm/llvm-project/pull/96721
Functions created with createWithDefaultAttr() need to have the
correct target-{cpu,features} attributes to avoid miscompilations
such as using the wrong relocation type to access globals (missing
tagged-globals featur
bwendling wrote:
This LGTM as well. I have a question about the "sub-object" part. Do we attempt
to discover the sub-object past any casting? A motivating example:
```c
char mux[10][10][10];
printf("%ld\n", __builtin_dynamic_object_size(&((char *)&mux[1][1])[var], 1));
```
GCC prints `89` (wh
https://github.com/zyn0217 edited
https://github.com/llvm/llvm-project/pull/96686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3216,6 +3226,44 @@ void DeclareImplicitDeductionGuidesForTypeAlias(
Guides.suppressDiagnostics();
for (auto *G : Guides) {
+if (auto *DG = dyn_cast(G)) {
+ // The deduction guide is a non-template function decl, we just clone it.
+ auto *FunctionType =
+
https://github.com/zyn0217 commented:
Thanks for the patch! I think the overall approach looks good, and with this
patch, I also need to remove the assumption in my
https://github.com/llvm/llvm-project/pull/96084 that there's always a template
decl associated with the deduction guide.
https:
https://github.com/zyn0217 edited
https://github.com/llvm/llvm-project/pull/96686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1059,9 +1059,10 @@
CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn,
if (Guard.isValid()) {
// If we have a guard variable, check whether we've already performed
// these initializations. This happens for TLS initialization functions.
- ll
https://github.com/HerrCai0907 approved this pull request.
LGTM. Thanks for your contribution.
https://github.com/llvm/llvm-project/pull/96617
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
FireBurn wrote:
I've just bisected to the faulty commit and eventaully to this fix
+1 to get this added to 18.1.9 if there ever is one - especially if the Android
NDK moves to it - the 27 betas fail for me too
https://github.com/llvm/llvm-project/pull/93206
https://github.com/HerrCai0907 updated
https://github.com/llvm/llvm-project/pull/96203
>From 669205c0f659239c58a3bde3ddadabb0a8ecbad8 Mon Sep 17 00:00:00 2001
From: Congcong Cai
Date: Thu, 20 Jun 2024 15:05:57 +
Subject: [PATCH 1/4] [clang-tidy] add fixhint for misc-use-internal-linkage
--
@@ -25,3 +25,16 @@ Example:
}
// already declared as extern
extern int v2;
+
+Options
+---
+
+.. option:: FixMode
+
+ Selects the fix mode when fixing automatically.
HerrCai0907 wrote:
```suggestion
Selects what kind of a fix the check should prov
ChuanqiXu9 wrote:
> Thanks for this patch, I will try it on our codebase to see the effects of it
> and report back to you. I am also trying to understand in which cases this
> would be a win and when not. IIUC, this is always a win when `ModuleFileIndex
> != 0` and a pessimization otherwise.
https://github.com/trcrsired edited
https://github.com/llvm/llvm-project/pull/96417
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jdenny-ornl wrote:
> I think this looks good overall,
Thanks for the fast reviews.
> though I'd like to hear some other clang maintainers chime in on the LIT
> config changes.
For reference, I mostly copied that from the llvm test suite config.
https://github.com/llvm/llvm-project/pull/96704
https://github.com/trcrsired updated
https://github.com/llvm/llvm-project/pull/96417
>From 049f249f0f5ff769224cf53b4d7be47bdac6196a Mon Sep 17 00:00:00 2001
From: trcrsired
Date: Sun, 23 Jun 2024 00:07:19 -0400
Subject: [PATCH] Support --sysroot= for ${arch}-windows-msvc targets
I think it is
https://github.com/trcrsired updated
https://github.com/llvm/llvm-project/pull/96417
>From 70823f780dc0748446c752f27b52b0f6061bc7e1 Mon Sep 17 00:00:00 2001
From: trcrsired
Date: Sun, 23 Jun 2024 00:07:19 -0400
Subject: [PATCH 1/2] Support --sysroot= for ${arch}-windows-msvc targets
I think it
https://github.com/jhuber6 approved this pull request.
I think this looks good overall, though I'd like to hear some other clang
maintainers chime in on the LIT config changes.
https://github.com/llvm/llvm-project/pull/96704
___
cfe-commits mailing li
@@ -0,0 +1,77 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
jhuber6 wrote:
I see, probably fine then.
https://github.com/llvm/llvm-project/pull/96704
___
cfe-commits mailing list
cfe-commits
https://github.com/jdenny-ornl edited
https://github.com/llvm/llvm-project/pull/96704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,77 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
jdenny-ornl wrote:
noinline prevents the inline pass in the test from running.
https://github.com/llvm/llvm-project/pull/96704
___
@@ -0,0 +1,77 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
jhuber6 wrote:
-disable-O0-optnone handles the optnone, don't think `noinline` affects that
much.
https://github.com/llvm/llvm-project/pull/96704
___
efriedma-quic wrote:
> Or, if we do need to preserve bitcode compat, how to best achieve it? Perhaps
> we convert them into inline-asm in the bitcode upgrader?
Really, the question is whether we plan to completely drop support for the
x86_mmx type (including inline asm operands/results). If w
https://github.com/jdenny-ornl edited
https://github.com/llvm/llvm-project/pull/96704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/h-vetinari edited
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,77 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
jdenny-ornl wrote:
OK, I did that. I used opt to discard the inline attribute that clang
introduces. If you know of a better way that doesn't perform inlining before
the c
https://github.com/jdenny-ornl updated
https://github.com/llvm/llvm-project/pull/96704
>From 98e04dd372b82c2c5309a6148bb49eb1012a97ee Mon Sep 17 00:00:00 2001
From: "Joel E. Denny"
Date: Tue, 25 Jun 2024 17:29:49 -0400
Subject: [PATCH 1/4] [LinkerWrapper] Extend with usual pass options
The goa
https://github.com/ahmedbougacha edited
https://github.com/llvm/llvm-project/pull/94056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
> Should we add a test for this flag? Something around existing tests in
> clang/test/CXX/temp/temp.spec/temp.expl.spec/p2-20.cpp and
> clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p1.cpp.
Oh, right, I did have a new test I meant to add, but that's a better place for
it - so I've
@@ -652,6 +652,134 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Tra
https://github.com/dwblaikie updated
https://github.com/llvm/llvm-project/pull/96699
>From a539afc7b81502ffcab7028bfe8266b8e32951d9 Mon Sep 17 00:00:00 2001
From: David Blaikie
Date: Tue, 25 Jun 2024 21:02:50 +
Subject: [PATCH 1/2] Clang: Add warning flag for storage class specifiers on
ex
https://github.com/HerrCai0907 closed
https://github.com/llvm/llvm-project/pull/96199
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Congcong Cai
Date: 2024-06-26T08:05:00+08:00
New Revision: 6b29965fd9355243f23a83a590a70ac7744f0e0f
URL:
https://github.com/llvm/llvm-project/commit/6b29965fd9355243f23a83a590a70ac7744f0e0f
DIFF:
https://github.com/llvm/llvm-project/commit/6b29965fd9355243f23a83a590a70ac7744f0e0f.diff
@@ -1336,75 +1336,56 @@ static llvm::Value *CreateCoercedLoad(Address Src,
llvm::Type *Ty,
return CGF.Builder.CreateLoad(Tmp);
}
-// Function to store a first-class aggregate into memory. We prefer to
-// store the elements rather than the aggregate to be more friendly to
@@ -0,0 +1,77 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
jdenny-ornl wrote:
Yeah, I suppose that's just as good. I do wonder if this is really the right
directory for these tests at all. Its lit.local.cfg has a %clang_cc1
substi
@@ -0,0 +1,77 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
jhuber6 wrote:
Hm, is this really the only LLVM-IR file in the Driver directory? I guess it
makes sense, though you could probably just do what the other linker wrapper
test
https://github.com/trcrsired updated
https://github.com/llvm/llvm-project/pull/96417
>From 70823f780dc0748446c752f27b52b0f6061bc7e1 Mon Sep 17 00:00:00 2001
From: trcrsired
Date: Sun, 23 Jun 2024 00:07:19 -0400
Subject: [PATCH] Support --sysroot= for ${arch}-windows-msvc targets
I think it is
@@ -0,0 +1,86 @@
+; Check various clang-linker-wrapper pass options after -offload-opt.
+
+; REQUIRES: llvm-plugins, llvm-examples
+; REQUIRES: x86-registered-target
+; REQUIRES: amdgpu-registered-target
+
+; Setup.
+; RUN: split-file %s %t
+; RUN: opt -o %t/host-x86_64-unknown-li
https://github.com/jdenny-ornl updated
https://github.com/llvm/llvm-project/pull/96704
>From 98e04dd372b82c2c5309a6148bb49eb1012a97ee Mon Sep 17 00:00:00 2001
From: "Joel E. Denny"
Date: Tue, 25 Jun 2024 17:29:49 -0400
Subject: [PATCH 1/3] [LinkerWrapper] Extend with usual pass options
The goa
jdenny-ornl wrote:
> Makes sense overall. However in the future I'm looking to move away from the
> home-baked LTO pipeline in favor of giving it to the linker. That allows me
> to set up libraries as a part of the target toolchain in the driver. I guess
> for that I'll just need to forward `-
jyknight wrote:
> I guess the clang calling convention code never uses MMX types for
> passing/returning values?
Correct, Clang never uses MMX types in its calling convention. This is actually
_wrong_ for the 32-bit x86 psABI. You're supposed to pass the first 3 MMX args
in mm0-2, and return
1 - 100 of 385 matches
Mail list logo
