https://github.com/ahatanak edited
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
preames wrote:
Once https://github.com/llvm/llvm-project/pull/90266 lands with the attributes
off by default, I think we should move forward with relanding this. We do need
one change though - our TSO lowering unconditionally uses the A6S ABI variant -
right? - so we need to adjust the attrib
Author: Akira Hatanaka
Date: 2024-06-25T08:33:05-07:00
New Revision: 2604830aacdd563715da030d0396b565e912436f
URL:
https://github.com/llvm/llvm-project/commit/2604830aacdd563715da030d0396b565e912436f
DIFF:
https://github.com/llvm/llvm-project/commit/2604830aacdd563715da030d0396b565e912436f.diff
@@ -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
ilya-biryukov wrote:
Maybe explicitly mention the user-facing effect of what "no transitive chan
@@ -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
https://github.com/ahatanak closed
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
delcypher wrote:
@ahatanak Excited to see this finally land 🎉
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AlexisPerry wrote:
I believe I've addressed all the review comments and all the checks have
passed. Could someone with commit access please merge this on my behalf?
Thank you.
https://github.com/llvm/llvm-project/pull/95043
___
cfe-commits mailing
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Alex Voicu (AlexVlx)
Changes
This is mostly stealing from #75357, and updating it to reflect the
pivot towards AMDGCN flavoured SPIR-V and the slightly different set of
limitations. As we bring up more functionality it will be updated acc
https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/96659
This is in support of WG14 N2848 which only define the macros if
infinity and nan are supported, so use of -ffinite-math will cause the
macros to not be defined.
>From b59c7f8c91d7c128975554d90bef3657ce3b272
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Aaron Ballman (AaronBallman)
Changes
This is in support of WG14 N2848 which only define the macros if
infinity and nan are supported, so use of -ffinite-math will cause the
macros to not be defined.
---
Full diff: https://github.com/llvm/l
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/96657
___
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.
LGTM
https://github.com/llvm/llvm-project/pull/96657
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -284,3 +284,48 @@ Example Usage
Base* basePtr = &obj;
basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
}
+
+SPIR-V Support on HIPAMD ToolChain
+==
+
+The HIPAMD ToolChain supports targetting
+`AMDG
@@ -2503,24 +2621,36 @@ StmtResult
Parser::ParseOpenMPDeclarativeOrExecutableDirective(
"Not an OpenMP directive!");
ParsingOpenMPDirectiveRAII DirScope(*this);
ParenBraceBracketBalancer BalancerRAIIObj(*this);
- SmallVector Clauses;
- std::bitset SeenClauses;
@@ -2374,88 +2374,206 @@ Parser::DeclGroupPtrTy
Parser::ParseOpenMPDeclarativeDirectiveWithExtDecl(
case OMPD_unknown:
Diag(Tok, diag::err_omp_unknown_directive);
break;
- case OMPD_parallel:
- case OMPD_simd:
- case OMPD_tile:
- case OMPD_unroll:
- case OMPD_ta
@@ -2503,24 +2621,36 @@ StmtResult
Parser::ParseOpenMPDeclarativeOrExecutableDirective(
"Not an OpenMP directive!");
ParsingOpenMPDirectiveRAII DirScope(*this);
ParenBraceBracketBalancer BalancerRAIIObj(*this);
- SmallVector Clauses;
- std::bitset SeenClauses;
Author: Timm Bäder
Date: 2024-06-25T17:50:53+02:00
New Revision: b7768c5485844306cd3c8afeef609ddf9d79696a
URL:
https://github.com/llvm/llvm-project/commit/b7768c5485844306cd3c8afeef609ddf9d79696a
DIFF:
https://github.com/llvm/llvm-project/commit/b7768c5485844306cd3c8afeef609ddf9d79696a.diff
LO
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/96374
___
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!
https://github.com/llvm/llvm-project/pull/96374
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> The `preserve_none` calling convention is new in clang 19 and hasn't been
> released yet; do fixes need a release note if they happen within the release
> cycle a feature is added?
Nope, no need for a release note in this case; I forgot that this was new for
clang 19 ra
AaronBallman wrote:
Do you need me to land the changes on your behalf?
https://github.com/llvm/llvm-project/pull/96487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
shiltian wrote:
you have test failure
https://buildkite.com/llvm-project/github-pull-requests/builds/73905#01902d01-7814-41af-b8e6-4d7d258fd4ec
and
https://buildkite.com/llvm-project/github-pull-requests/builds/73905#01902d01-7817-438a-b2cc-554580bfe611.
Need to get it fixed before we merge i
yronglin wrote:
Friendly ping~
https://github.com/llvm/llvm-project/pull/90574
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AlexVlx commented:
> I'll need to play with this with my driver code. I'm guessing it's because it
> needs to generate an entirely separate toolchain? The OpenMP path basically
> does that by inferring the toolchain from the string value, so we can support
> `--offload-arch=
https://github.com/AlexVlx edited
https://github.com/llvm/llvm-project/pull/96657
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2374,88 +2374,206 @@ Parser::DeclGroupPtrTy
Parser::ParseOpenMPDeclarativeDirectiveWithExtDecl(
case OMPD_unknown:
Diag(Tok, diag::err_omp_unknown_directive);
break;
- case OMPD_parallel:
- case OMPD_simd:
- case OMPD_tile:
- case OMPD_unroll:
- case OMPD_ta
@@ -2503,24 +2621,36 @@ StmtResult
Parser::ParseOpenMPDeclarativeOrExecutableDirective(
"Not an OpenMP directive!");
ParsingOpenMPDirectiveRAII DirScope(*this);
ParenBraceBracketBalancer BalancerRAIIObj(*this);
- SmallVector Clauses;
- std::bitset SeenClauses;
AaronBallman wrote:
Link to WG14 N2848: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2848.pdf
https://github.com/llvm/llvm-project/pull/96659
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
var-const wrote:
@ahatanak Thank you so much for pushing this through! This will be awesome for
our hardening effort in libc++. Thanks to everyone for all the feedback and
discussions as well!
https://github.com/llvm/llvm-project/pull/79230
___
cfe-c
https://github.com/CedricSwa updated
https://github.com/llvm/llvm-project/pull/94865
>From 012849c5410960001ca5bbcb90ea2cf4a661b840 Mon Sep 17 00:00:00 2001
From: Cedric Schwarzer
Date: Sat, 8 Jun 2024 17:52:02 +0200
Subject: [PATCH 1/4] Improve error message for invalid lambda captures
---
c
efriedma-quic wrote:
Do we want some sort of optimization for constant printf? 99% of the time, we
could parse the string at compile-time. (This sort of optimization is common
for embedded targets.)
If the format string isn't constant, is parsing the string on the GPU really
slower than ask
ilya-biryukov 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.
When
https://github.com/alexey-bataev approved this pull request.
LG
https://github.com/llvm/llvm-project/pull/94691
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> > I'll need to play with this with my driver code. I'm guessing it's because
> > it needs to generate an entirely separate toolchain? The OpenMP path
> > basically does that by inferring the toolchain from the string value, so we
> > can support `--offload-arch=sm_89,gfx90a` f
jhuber6 wrote:
> Do we want some sort of optimization for constant printf? 99% of the time, we
> could parse the string at compile-time. (This sort of optimization is common
> for embedded targets.)
I was going to make a follow-up patch that simply skipped sending back the size
if there were
jhuber6 wrote:
Also, I just merged the prerequisite patches into this, to get the relevant
changed just look at the most recent commit. The lack of stacked PRs in GitHub
really irks me.
https://github.com/llvm/llvm-project/pull/96369
___
cfe-commits
efriedma-quic wrote:
(I'd like a re-review of the latest version: I made significant revisions to
address the tail-padding issues.)
https://github.com/llvm/llvm-project/pull/93115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.l
https://github.com/5chmidti approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/96122
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/5chmidti approved this pull request.
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
efriedma-quic wrote:
I guess the clang calling convention code never uses MMX types for
passing/returning values?
Have you looked at the code quality? #41665 mentions potential issues with
widening vectors.
This doesn't touch inline asm or _mm_empty; I guess you're leaving that for a
follow
Author: Timm Bäder
Date: 2024-06-25T18:32:12+02:00
New Revision: 580343d96f18e3c2fa8d7a8e25a175aaa2e20522
URL:
https://github.com/llvm/llvm-project/commit/580343d96f18e3c2fa8d7a8e25a175aaa2e20522
DIFF:
https://github.com/llvm/llvm-project/commit/580343d96f18e3c2fa8d7a8e25a175aaa2e20522.diff
LO
https://github.com/NagyDonat approved this pull request.
LGTM.
I'm a bit surprised to see that this checker duplicates the logic of the array
bounds checkers (in the special case when the indexing operation is within a
pointer subtraction). Right now this is OK but we'll need to delete this on
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/96501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Aaron Ballman
Date: 2024-06-25T12:34:34-04:00
New Revision: 05ca20744159a33349271a96b90959a0a3807133
URL:
https://github.com/llvm/llvm-project/commit/05ca20744159a33349271a96b90959a0a3807133
DIFF:
https://github.com/llvm/llvm-project/commit/05ca20744159a33349271a96b90959a0a3807133.diff
Author: PeterChou1
Date: 2024-06-25T09:39:33-07:00
New Revision: d7dd778cde84110e38521a6b55dfeb4e1c649ec2
URL:
https://github.com/llvm/llvm-project/commit/d7dd778cde84110e38521a6b55dfeb4e1c649ec2
DIFF:
https://github.com/llvm/llvm-project/commit/d7dd778cde84110e38521a6b55dfeb4e1c649ec2.diff
LO
https://github.com/ilovepi closed
https://github.com/llvm/llvm-project/pull/96555
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: PeterChou1
Date: 2024-06-25T09:40:58-07:00
New Revision: dbd5c7805bae510c79b51c2c7700a590f2df446d
URL:
https://github.com/llvm/llvm-project/commit/dbd5c7805bae510c79b51c2c7700a590f2df446d
DIFF:
https://github.com/llvm/llvm-project/commit/dbd5c7805bae510c79b51c2c7700a590f2df446d.diff
LO
https://github.com/ilovepi closed
https://github.com/llvm/llvm-project/pull/96552
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AlexVlx wrote:
> > > I'll need to play with this with my driver code. I'm guessing it's
> > > because it needs to generate an entirely separate toolchain? The OpenMP
> > > path basically does that by inferring the toolchain from the string
> > > value, so we can support `--offload-arch=sm_89,g
@@ -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
ilovepi wrote:
The two complementary patches, making the test free standing, and fixing the
default asset path to be `share/clang-doc` have landed now. Can you update your
patch, and resolve conflicts. If that passes CI, then I think we're probably
about ready to reland.
https://github.com/ll
jhuber6 wrote:
> I looked at this and it doesn't look super appealing (turned into something
> of a rabbit hole), it'd duplicate a lot of the existing toolchain, and would
> also try to squat in an already overcrowded space (there's already HIPSPV).
We already have a SPIR-V toolchain for HIP?
@@ -614,12 +623,15 @@ _mm_shuffle_epi8(__m128i __a, __m128i __b)
///1: Clear the corresponding byte in the destination. \n
///0: Copy the selected source byte to the corresponding byte in the
///destination. \n
-///Bits [3:0] select the source byte to be copied.
Author: Aaron Ballman
Date: 2024-06-25T12:46:41-04:00
New Revision: 5e2beed9a1643cd6358fb8b43feb893543d90bf3
URL:
https://github.com/llvm/llvm-project/commit/5e2beed9a1643cd6358fb8b43feb893543d90bf3
DIFF:
https://github.com/llvm/llvm-project/commit/5e2beed9a1643cd6358fb8b43feb893543d90bf3.diff
@@ -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)));
RKSimon wrote:
Add a deprecation message if SSE2 is not defined or j
RKSimon wrote:
> > So can we get all the mmx patches done in time for the 19.0 branch?
>
> Maybe? Depends on how the discussion on the other PR goes -- whether that
> proposal is acceptable, or if a different transition strategy is desired.
Apart from #96540 how many more patches do you envisi
https://github.com/rymdtian updated
https://github.com/llvm/llvm-project/pull/95957
>From 5f6da1bf00c4b3bdb8aa75913629ebee262f3783 Mon Sep 17 00:00:00 2001
From: Raymond Tian
Date: Tue, 18 Jun 2024 09:58:32 -0700
Subject: [PATCH] [HIP][Clang][Sema] Fix crash when calling builtins with
pointer
nickdesaulniers wrote:
> Do we want some sort of optimization for constant printf? 99% of the time, we
> could parse the string at compile-time. (This sort of optimization is common
> for embedded targets.)
Yes! @michaelrj-google has some ideas. Orthogonal to this PR though.
https://github.co
SLTozer wrote:
> My guess here would have been that the issue is the cases where an
> Instruction* or BasicBlock* is passed rather than BB+Iterator, because those
> two cases go through an out-of-line constructor.
Seems like you're right - removing the extra dereference does
little-to-nothing
https://github.com/rnk commented:
Thanks for looking at this, let's make this an error instead of a crash in the
future.
https://github.com/llvm/llvm-project/pull/96487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/96487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2986,6 +2989,9 @@ void
MicrosoftCXXNameMangler::mangleCallingConvention(CallingConv CC) {
case CC_Swift: Out << 'S'; break;
case CC_SwiftAsync: Out << 'W'; break;
case CC_PreserveMost: Out << 'U'; break;
+case CC_PreserveNone:
+ Out << 'V';
---
@@ -2986,6 +2989,9 @@ void
MicrosoftCXXNameMangler::mangleCallingConvention(CallingConv CC) {
case CC_Swift: Out << 'S'; break;
rnk wrote:
The default case here should be a proper compiler error, not an unreachable,
since there's no good way to prevent arb
https://github.com/efriedma-quic commented:
I'm not sure about tying this to __FINITE_MATH_ONLY__; -ffinite-math-only
doesn't mean infinity doesn't exist, it just means you're promising that you
won't use floating-point arithmetic/comparison ops on infinity. Which is
weird, but that's fast-ma
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/96659
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/michaelrj-google edited
https://github.com/llvm/llvm-project/pull/96369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,73 @@
+//===--- GPU helper functions for printf using RPC
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
@@ -54,7 +54,8 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter =
michaelrj-google wrote:
why was this change made?
https://github.com/llvm/llvm-project/pull/96369
https://github.com/michaelrj-google commented:
I thought I submitted these comments already, oops
https://github.com/llvm/llvm-project/pull/96369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
@@ -5368,16 +5368,85 @@ The ``#pragma comment(lib, ...)`` directive is
supported on all ELF targets.
The second parameter is the library name (without the traditional Unix prefix
of
``lib``). This allows you to provide an implicit link of dependent libraries.
-Evaluating Ob
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/96573
>From 3394d999888087535db9ede87668829eddc33ac7 Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Mon, 24 Jun 2024 15:52:18 -0700
Subject: [PATCH 1/2] Add documentation for `__builtin_object_size`.
Explicitly d
@@ -54,7 +54,8 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter =
jhuber6 wrote:
I now use the `MockArgList` to tell determine how big the "struct" needs to be
to contain the arguments.
https://github.co
@@ -0,0 +1,73 @@
+//===--- GPU helper functions for printf using RPC
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
@@ -0,0 +1,73 @@
+//===--- GPU helper functions for printf using RPC
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
@@ -54,7 +54,8 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter =
michaelrj-google wrote:
in that case it'd be better to create a new `ArgList` that is intended to count
sizes instead of just modifying th
AaronBallman wrote:
> I'm not sure about tying this to `__FINITE_MATH_ONLY__`; -ffinite-math-only
> doesn't mean infinity doesn't exist, it just means you're promising that you
> won't use floating-point arithmetic/comparison ops on infinity. Which is
> weird, but that's fast-math. Also, other
https://github.com/PeterChou1 updated
https://github.com/llvm/llvm-project/pull/96358
>From bb407e7c6de15d7ed2f0dd645ca2a469ee1f8a8e Mon Sep 17 00:00:00 2001
From: PeterChou1
Date: Fri, 21 Jun 2024 16:57:30 -0400
Subject: [PATCH 1/4] Revert "Revert "[clang-doc] Add --asset option to
clang-doc"
@@ -54,7 +54,8 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter =
jhuber6 wrote:
I didn't see any tests that actively depended on this value, and figured that
it does a similar job stating how many bytes
Author: Alexis Perry-Holby
Date: 2024-06-25T18:39:35+01:00
New Revision: a790279bf2a8be2f9c42bf80f55a63933e398d0e
URL:
https://github.com/llvm/llvm-project/commit/a790279bf2a8be2f9c42bf80f55a63933e398d0e
DIFF:
https://github.com/llvm/llvm-project/commit/a790279bf2a8be2f9c42bf80f55a63933e398d0e.
https://github.com/banach-space closed
https://github.com/llvm/llvm-project/pull/95043
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> and that implies (at least to me) that an expression cannot form an infinity
> to begin with, so the act of trying to expand INFINITY is nonsensical in that
> case, right?
It's undefined behavior at runtime.
I don't think we need to worry too much about what the C stand
@@ -54,7 +54,8 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter =
michaelrj-google wrote:
I don't think anything directly depends on its output, but also the comments on
it specifically say that it's for
AaronBallman wrote:
> > and that implies (at least to me) that an expression cannot form an
> > infinity to begin with, so the act of trying to expand INFINITY is
> > nonsensical in that case, right?
>
> It's undefined behavior at runtime.
>
> I don't think we need to worry too much about wha
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-cuda-l4` running on
`cuda-l4-0` while building `clang,flang,mlir` at step 3 "annotate".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/101/builds/691
Here is the relevant piece of the build log
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `flang-aarch64-libcxx`
running on `linaro-flang-aarch64-libcxx` while building `clang,flang,mlir` at
step 6 "test-build-unified-tree-check-flang".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/89/buil
ilovepi wrote:
Seems like a tidy test is failing on windows ... can you try updating the
branch once more?
https://github.com/llvm/llvm-project/pull/96358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
Author: Aaron Ballman
Date: 2024-06-25T14:02:05-04:00
New Revision: a0869331ec0c9ae42f696e87d72416ea5ecb926f
URL:
https://github.com/llvm/llvm-project/commit/a0869331ec0c9ae42f696e87d72416ea5ecb926f
DIFF:
https://github.com/llvm/llvm-project/commit/a0869331ec0c9ae42f696e87d72416ea5ecb926f.diff
@@ -0,0 +1,174 @@
+// RUN: %clang -Wno-constant-conversion -Wno-array-bounds
-Wno-division-by-zero -Wno-shift-negative-value -Wno-shift-count-negative
-Wno-int-to-pointer-cast -O0
-fsanitize=alignment,array-bounds,bool,float-cast-overflow,implicit-integer-sign-change,implicit-s
banach-space wrote:
> LLVM Buildbot has detected a new failure on builder `flang-aarch64-libcxx`
> running on `linaro-flang-aarch64-libcxx` while building `clang,flang,mlir` at
> step 6 "test-build-unified-tree-check-flang".
>
> Full details are available at:
> https://lab.llvm.org/buildbot/#
https://github.com/shiltian approved this pull request.
LG and good to know we have format support :-)
https://github.com/llvm/llvm-project/pull/96650
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
https://github.com/AaronBallman approved this pull request.
Thank you for the additional docs, they LGTM!
https://github.com/llvm/llvm-project/pull/96573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
Author: Joseph Huber
Date: 2024-06-25T13:16:28-05:00
New Revision: b9353f7f3ec88ecc5c4cdfc109665c89599b7f2f
URL:
https://github.com/llvm/llvm-project/commit/b9353f7f3ec88ecc5c4cdfc109665c89599b7f2f
DIFF:
https://github.com/llvm/llvm-project/commit/b9353f7f3ec88ecc5c4cdfc109665c89599b7f2f.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/96650
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -54,7 +54,8 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter =
jhuber6 wrote:
Done
https://github.com/llvm/llvm-project/pull/96369
___
cfe-commits mailing li
@@ -216,6 +228,35 @@ u64 GetShadowCount(uptr p, u32 size) {
return count;
}
+// Accumulates the access count from the shadow for the given pointer and size.
+// See memprof_mapping.h for an overview on histogram counters.
+u64 GetShadowCountHistogram(uptr p, u32 size) {
+ u
https://github.com/mattweingarten updated
https://github.com/llvm/llvm-project/pull/94264
error: too big or took too long to generate
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/teresajohnson approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/94264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
101 - 200 of 385 matches
Mail list logo
