https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/132061
>From fb9fa67da10a7dbfb2db5520d2773085585f4c14 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Thu, 20 Mar 2025 00:54:54 +0800
Subject: [PATCH 1/3] [Clang] Fix various bugs in alias CTAD transform
---
clang/
https://github.com/vikramRH updated
https://github.com/llvm/llvm-project/pull/129495
>From 5f801892269bcd08e42722dc64d66d1f8d054612 Mon Sep 17 00:00:00 2001
From: vikhegde
Date: Fri, 27 Dec 2024 05:06:29 +
Subject: [PATCH 1/2] [Clang] Support floating point vectors with atomic
builtins
--
@@ -2312,6 +2312,17 @@ bool Type::isRealType() const {
return isBitIntType();
}
+bool Type::isFPAtomicCompatibleType() const {
vikramRH wrote:
not sure if this is the right place for the predicate, ASTContext seemed like a
good option too
https://github.c
https://github.com/cor3ntin approved this pull request.
https://github.com/llvm/llvm-project/pull/127629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -215,6 +221,8 @@ class CGBuilderTy : public CGBuilderBaseTy {
///
/// This API assumes that drilling into a struct like this is always an
/// inbounds and nuw operation.
+ /// Specifically, inbounds flag will not be set if \p IsBaseConstantNull is
+ /// true.
---
kadircet wrote:
Hi folks, we're seeing some regressions on our internal tidy checks after this
patch.
The regression is similar to what @haoNoQ raised in
https://github.com/llvm/llvm-project/pull/128150#issuecomment-2705425193, the
blast radius a little bit wider than checks that build and in
https://github.com/jthackray approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/132167
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130734
>From b9876822acdca4eaea6496a1d6471e2c0f4ad2e1 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 11 Mar 2025 16:20:08 +0800
Subject: [PATCH 1/7] [Clang][CodeGen] Do not set inbounds flag for struct GEP
wi
@@ -148,6 +160,24 @@ class AnnotatingParser {
}
}
+ const FormatStyle::FunctionDeclarationWithKeywords *
+ isInsideFunctionWithKeywordedParameters(const FormatToken &Token) const {
+const FormatToken *Previous = &Token;
+while (auto Prev = Previous->getPrevious
https://github.com/usx95 updated
https://github.com/llvm/llvm-project/pull/131997
>From 9220b14a8147850a39e2c9bdf1188f2135b7a0ae Mon Sep 17 00:00:00 2001
From: Utkarsh Saxena
Date: Wed, 19 Mar 2025 10:25:07 +
Subject: [PATCH 1/2] [clang] Do not infer lifetimebound for functions with
void r
https://github.com/usx95 updated
https://github.com/llvm/llvm-project/pull/131997
>From 9220b14a8147850a39e2c9bdf1188f2135b7a0ae Mon Sep 17 00:00:00 2001
From: Utkarsh Saxena
Date: Wed, 19 Mar 2025 10:25:07 +
Subject: [PATCH 1/2] [clang] Do not infer lifetimebound for functions with
void r
@@ -0,0 +1,342 @@
+//===--- UseScopedLockCheck.cpp - clang-tidy
--===//
+//
+// 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: Ap
PiotrZSL wrote:
checkfactories could read name of checks from an options config.
https://github.com/llvm/llvm-project/pull/131804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
frasercrmck wrote:
Note that this work is the result of asking the LLVM Foundation about the state
of libclc licensing, and their checking with the Foundation's IP lawyer. I've
CC'd @kbeyls for confirmation.
> I'll just put it out there since my name's on a bunch of these files and it
> might
yuvald-sweet-security wrote:
> @yuvald-sweet-security Could you share which kernel you are used for above
> testing?
I ran this on my host machine which is Windows with WSL, kernel
`6.6.75.1-microsoft-standard-WSL2`. However, I can see similar regressions on
pretty much every testing VM that
https://github.com/HighCommander4 edited
https://github.com/llvm/llvm-project/pull/128503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,24 +1,10 @@
-/*
- * Copyright (c) 2015 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this software and associated documentation files (the "Software"), to
deal
- * in the Software without restriction
https://github.com/XiaShark created
https://github.com/llvm/llvm-project/pull/132167
Currently, clang incorrectly defines the `__ARM_FEATURE_CRC32` macro even when
`-crc` is explicitly specified in `-target-feature`. This can lead to
unexpected behavior in code that relies on this macro.
See t
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-backend-aarch64
Author: None (XiaShark)
Changes
Currently, clang incorrectly defines the `__ARM_FEATURE_CRC32` macro even when
`-crc` is explicitly specified in `-target-feature`. This can lead to
unexpected behavior in code
phoebewang wrote:
> > > > Went through the patch with my eyes, I'm not sure how useful it was but
> > > > wasn't able to spot anything.
> > > > > Here is GCC patch:
> > > > > https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678227.html
> > > >
> > > >
> > > > I haven't found any changes r
@@ -1752,7 +1752,8 @@ enum class StringLiteralKind {
UTF8,
UTF16,
UTF32,
- Unevaluated
+ Unevaluated,
+ Binary
cor3ntin wrote:
Yup, Thanks!
https://github.com/llvm/llvm-project/pull/127629
___
cfe-commits m
https://github.com/Fznamznon updated
https://github.com/llvm/llvm-project/pull/127629
>From 700ec6f78c0a24729801bea381bafbcafb06826b Mon Sep 17 00:00:00 2001
From: "Podchishchaeva, Mariya"
Date: Tue, 18 Feb 2025 05:12:07 -0800
Subject: [PATCH 1/3] [clang] Introduce "binary" StringLiteral for #e
Author: Amr Hesham
Date: 2025-03-20T08:07:28+01:00
New Revision: 7c6479021382b5cf16619f0089b9d86536630e26
URL:
https://github.com/llvm/llvm-project/commit/7c6479021382b5cf16619f0089b9d86536630e26
DIFF:
https://github.com/llvm/llvm-project/commit/7c6479021382b5cf16619f0089b9d86536630e26.diff
LO
https://github.com/AmrDeveloper closed
https://github.com/llvm/llvm-project/pull/132093
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jianghc724 wrote:
> > Went through the patch with my eyes, I'm not sure how useful it was but
> > wasn't able to spot anything.
> > > Here is GCC patch:
> > > https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678227.html
> >
> >
> > I haven't found any changes regarding `vcvt2ph2` and no o
https://github.com/sarnex approved this pull request.
https://github.com/llvm/llvm-project/pull/132037
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/132061
>From fb9fa67da10a7dbfb2db5520d2773085585f4c14 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Thu, 20 Mar 2025 00:54:54 +0800
Subject: [PATCH 1/2] [Clang] Fix various bugs in alias CTAD transform
---
clang/
@@ -1348,6 +1348,16 @@ std::optional
Sema::isSFINAEContext() const {
return std::nullopt;
}
+static TemplateArgument
+getPackSubstitutedTemplateArgument(Sema &S, TemplateArgument Arg) {
zyn0217 wrote:
This is pre-existing - do I have to rename that?
https
Rejur wrote:
> > > Went through the patch with my eyes, I'm not sure how useful it was but
> > > wasn't able to spot anything.
> > > > Here is GCC patch:
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678227.html
> > >
> > >
> > > I haven't found any changes regarding `vcvt2ph2`
@@ -3660,6 +3660,8 @@ class TreeTransform {
return SemaRef.BuildCXXNoexceptExpr(Range.getBegin(), Arg, Range.getEnd());
}
+ bool HeuristicallyComputeSizeOfPackExpr() const { return true; }
+
zyn0217 wrote:
I choose to extract a function `ComputeSizeOfP
@@ -1077,7 +1077,11 @@ BuildDeductionGuideForTypeAlias(Sema &SemaRef,
// !!NOTE: DeduceResults respects the sequence of template parameters of
// the deduction guide f.
for (unsigned Index = 0; Index < DeduceResults.size(); ++Index) {
-if (const auto &D = DeduceResult
@@ -114,22 +114,23 @@ static Value *handleHlslClip(const CallExpr *E,
CodeGenFunction *CGF) {
CMP = CGF->Builder.CreateIntrinsic(
CGF->Builder.getInt1Ty(), CGF->CGM.getHLSLRuntime().getAnyIntrinsic(),
{FCompInst}, nullptr);
- } else
+ } else {
CMP =
https://github.com/jayfoad edited
https://github.com/llvm/llvm-project/pull/131942
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,342 @@
+//===--- UseScopedLockCheck.cpp - clang-tidy
--===//
+//
+// 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: Ap
https://github.com/dtcxzyw updated
https://github.com/llvm/llvm-project/pull/130734
>From b9876822acdca4eaea6496a1d6471e2c0f4ad2e1 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng
Date: Tue, 11 Mar 2025 16:20:08 +0800
Subject: [PATCH 1/6] [Clang][CodeGen] Do not set inbounds flag for struct GEP
wi
HerrCai0907 wrote:
> checkfactories could read name of checks from an options config.
Then everything go back. checkfactories or some other part in core will parse
the options and create check instance. It is similar as what this pr did.
Put everything in config also have some disadvantages, b
Xazax-hun wrote:
This is unfortunate. I think `hasAncestor/hasParent` and co should still be
able to reach nodes from system headers. We should either fix those or add an
escape hatch/revert back to the old behavior/look for another approach.
https://github.com/llvm/llvm-project/pull/128150
_
https://github.com/frasercrmck closed
https://github.com/llvm/llvm-project/pull/132070
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/offsetof updated
https://github.com/llvm/llvm-project/pull/131777
>From ff54ffd5ac3f761c877eebce52ef81d096d98f16 Mon Sep 17 00:00:00 2001
From: offsetof
Date: Tue, 18 Mar 2025 10:08:56 +
Subject: [PATCH 1/3] [clang] Improve checking of operator functions
* Move validatio
https://github.com/zyn0217 edited
https://github.com/llvm/llvm-project/pull/132061
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`clang-cmake-x86_64-avx512-win` running on `avx512-intel64-win` while building
`clang` at step 4 "cmake stage 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/81/builds/5440
Here is the relevant pi
https://github.com/AaronBallman commented:
This is awesome, thank you for working on it! One question I have is whether we
can also add a helper function for emitting these diagnostics. It's almost
always an awkward dance of `getLangOpts().CPlusPlusYZ ? diag::ext_... :
diag::warn_...` and it w
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`ppc64le-lld-multistage-test` running on `ppc64le-lld-multistage-test` while
building `clang` at step 12 "build-stage2-unified-tree".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/168/builds/9949
He
AaronBallman wrote:
> Needs release note.
>
> The big thing I'm not sure about is whether we want a corresponding warning.
> We're detecting a pattern we know has undefined behavior, so we should maybe
> warn? CC @AaronBallman @erichkeane
This pattern is undefined behavior, but we're wanting
Author: Mariya Podchishchaeva
Date: 2025-03-20T13:02:29+01:00
New Revision: 8c6f309023a9c5b6d8488e89ed0be8da7d117a68
URL:
https://github.com/llvm/llvm-project/commit/8c6f309023a9c5b6d8488e89ed0be8da7d117a68
DIFF:
https://github.com/llvm/llvm-project/commit/8c6f309023a9c5b6d8488e89ed0be8da7d117a
shiltian wrote:
Yeah, that needs to be fixed. The command line argument is
`--target=hexagon-unknown-elf-unknown`, which is a valid target triple, but the
error is `hexagon-unknown-unknown-elf-unknown`. That definitely exposes the
issue in the compiler driver.
https://github.com/llvm/llvm-pro
@@ -4143,6 +4143,7 @@ Sema::IsStringLiteralToNonConstPointerConversion(Expr
*From, QualType ToType) {
// We don't allow UTF literals to be implicitly converted
break;
case StringLiteralKind::Ordinary:
+ case StringLiteralKind::Binary:
frasercrmck wrote:
You're right, my mistake: even on this repo.
I was using `llvm-diff` and only checking the error code. It reports e.g.,
`function @_Z9__clc_minDv16_DhDh exists only in left module` but still returns
`0` so I missed it.
This only affects the `builtin.link.*` bytecode librari
https://github.com/mizvekov closed
https://github.com/llvm/llvm-project/pull/130537
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lldb-x86_64-debian`
running on `lldb-x86_64-debian` while building `clang-tools-extra,clang` at
step 4 "build".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/162/builds/18521
Here is the relevant p
Author: Wenju He
Date: 2025-03-20T13:25:55Z
New Revision: cb1e91c18dd20f6b2d1c38ce93befab87f77ce0f
URL:
https://github.com/llvm/llvm-project/commit/cb1e91c18dd20f6b2d1c38ce93befab87f77ce0f
DIFF:
https://github.com/llvm/llvm-project/commit/cb1e91c18dd20f6b2d1c38ce93befab87f77ce0f.diff
LOG: [lib
https://github.com/frasercrmck closed
https://github.com/llvm/llvm-project/pull/130871
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -10,12 +10,46 @@ struct S {
// CHECK-LABEL: @_Z23get_offset_of_y_naivelyv(
// CHECK-NEXT: entry:
-// CHECK-NEXT:ret i64 ptrtoint (ptr getelementptr inbounds nuw
([[STRUCT_S:%.*]], ptr null, i32 0, i32 1) to i64)
+// CHECK-NEXT:ret i64 ptrtoint (ptr getelementptr (
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`cross-project-tests-sie-ubuntu-dwarf5` running on `doug-worker-1b` while
building `clang-tools-extra,clang` at step 5 "build-unified-tree".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/163/builds/15
AaronBallman wrote:
Please also be sure to add enough information to the PR summary to explain why
the changes are needed (the summary becomes the commit message).
https://github.com/llvm/llvm-project/pull/132116
___
cfe-commits mailing list
cfe-commi
@@ -42,6 +42,11 @@ Potentially Breaking Changes
C/C++ Language Potentially Breaking Changes
---
+- Some old-style offsetof idioms like ``((int)(&(((struct S *)0)->field)))``
are treated
AaronBallman wrote:
This isn't r
llvmbot wrote:
@llvm/pr-subscribers-clang-tidy
Author: Matheus Izvekov (mizvekov)
Changes
Reverts llvm/llvm-project#130537
This missed updating lldb, which we didn't notice due to lack of pre-commit CI.
---
Patch is 141.44 KiB, truncated to 20.00 KiB below, full version:
https://github
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Matheus Izvekov (mizvekov)
Changes
Reverts llvm/llvm-project#130537
This missed updating lldb, which we didn't notice due to lack of pre-commit CI.
---
Patch is 141.44 KiB, truncated to 20.00 KiB below, full version:
https://github.com/
llvmbot wrote:
@llvm/pr-subscribers-clangd
Author: Matheus Izvekov (mizvekov)
Changes
Reverts llvm/llvm-project#130537
This missed updating lldb, which we didn't notice due to lack of pre-commit CI.
---
Patch is 141.44 KiB, truncated to 20.00 KiB below, full version:
https://github.com
https://github.com/dmpolukhin edited
https://github.com/llvm/llvm-project/pull/132214
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov closed
https://github.com/llvm/llvm-project/pull/132215
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > One question I have is whether we can also add a helper function for
> > emitting these diagnostics.
>
> I was thinking about that too. My first idea was that if we can rely on the
> order of records in tablegen influencing the order of diagnostic IDs, then
> one idea
https://github.com/AaronBallman approved this pull request.
LGTM but please wait for some additional opinions from other reviewers before
landing.
https://github.com/llvm/llvm-project/pull/132129
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
phoebewang wrote:
> should be cvts_biasph_hf8 :)
Good catch! Proves moving the s ahead is wisdom :)
https://github.com/llvm/llvm-project/pull/131592
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
mizvekov wrote:
Oof, looks like lldb needs updating too.
https://github.com/llvm/llvm-project/pull/130537
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> I think hasAncestor/hasParent and co should still be able to reach nodes
> from system headers.
I think the naive expectation is that these would be able to reach nodes in
system headers, so I agree that it would be good to see if we can improve the
behavior here. CC @c
erichkeane wrote:
> LGTM but please wait for some additional opinions from other reviewers before
> landing.
I don't actually spend much time writing compatibility warnings, but think this
is an improvement.
As a followup perhaps, I would LOVE it if we could modify the
DiagnosticsEmitter t
frasercrmck wrote:
It strikes me as a swiftshader bug. If `x` is a denormal/subnormal number and
it is being untouched by this function and really reaching this comparison as
`0x1.008p-140` then I don't believe it should ever compare true against `0.0`.
My reading of flush-to-zero
([here](htt
@@ -155,6 +155,38 @@ class DefaultWarnNoWerror {
}
class DefaultRemark { Severity DefaultSeverity = SEV_Remark; }
+// C++ compatibility warnings.
+multiclass CXXCompat<
+string message,
+int std_ver,
+bit ext_warn = true,
+string std_ver_override = ""#std_ver>
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/132061
>From fb9fa67da10a7dbfb2db5520d2773085585f4c14 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Thu, 20 Mar 2025 00:54:54 +0800
Subject: [PATCH 1/4] [Clang] Fix various bugs in alias CTAD transform
---
clang/
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`openmp-offload-libc-amdgpu-runtime` running on `omp-vega20-1` while building
`clang` at step 7 "Add check check-offload".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/73/builds/14951
Here is the r
@@ -155,6 +155,38 @@ class DefaultWarnNoWerror {
}
class DefaultRemark { Severity DefaultSeverity = SEV_Remark; }
+// C++ compatibility warnings.
+multiclass CXXCompat<
+string message,
+int std_ver,
+bit ext_warn = true,
+string std_ver_override = ""#std_ver>
@@ -155,6 +155,38 @@ class DefaultWarnNoWerror {
}
class DefaultRemark { Severity DefaultSeverity = SEV_Remark; }
+// C++ compatibility warnings.
+multiclass CXXCompat<
+string message,
+int std_ver,
+bit ext_warn = true,
+string std_ver_override = ""#std_ver>
@@ -284,6 +284,8 @@ Improvements to Clang's diagnostics
- Improve the ``-Wundefined-func-template`` warning when a function template
is not instantiated due to being unreachable in modules.
+- Clang now emits a ``-Wignored-cv-qualifiers`` diagnostic when a base class
includ
https://github.com/AaronBallman approved this pull request.
LGTM assuming precommit CI is happy with it.
https://github.com/llvm/llvm-project/pull/132201
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `llvm-x86_64-debian-dylib`
running on `gribozavr4` while building `clang-tools-extra,clang` at step 5
"build-unified-tree".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/60/builds/22602
Here is the
https://github.com/preames approved this pull request.
LGTM
One point of possible concern is that the version number collapses to 0.0 in
all of our tracking. I'm fine with this, but it's unfortunate, and possible
confusing. If the next version is 0.1, we're fine. If the next version is
0.0
justincady wrote:
This is the buildbot failure from the initial commit:
https://lab.llvm.org/buildbot/#/builders/133/builds/13131
I updated the failing test with the same restrictions as other tests using
`-fuse-ld=lld` under `compiler-rt/test/profile/Linux`, specifically:
```
// REQUIRES: ll
@@ -0,0 +1,1079 @@
+//===-- RISCVInstrInfoP.td - RISC-V 'P' instructions ---*- tablegen
-*-===//
+//
+// 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: A
https://github.com/topperc edited
https://github.com/llvm/llvm-project/pull/123271
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,1079 @@
+//===-- RISCVInstrInfoP.td - RISC-V 'P' instructions ---*- tablegen
-*-===//
+//
+// 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: A
https://github.com/justincady created
https://github.com/llvm/llvm-project/pull/13
Relands #130976 with adjustments to test requirements.
Calls to __noreturn__ functions result in region termination for
coverage mapping. But this creates incorrect coverage results when
__noreturn__ function
https://github.com/TilakChad updated
https://github.com/llvm/llvm-project/pull/124609
>From c865ba50fd3c1a5d427069e29e035c1d6e3d21d3 Mon Sep 17 00:00:00 2001
From: Tilak Chad
Date: Fri, 14 Mar 2025 00:44:10 +0545
Subject: [PATCH 1/3] [Clang] Dependent CallExpr having UnresolvedLookupExpr
are n
MagentaTreehouse wrote:
> The more I think about it, the more I think that we should modify the warning
> to only happen on EXPLICIT qualifiers. So:
>
> ```
> struct Base{};
> using CBase = const Base;
>
> struct D1 : const Base {}; // DOES warn
> struct D2 : CBase{}; // a DIFFERENT warning (s
@@ -548,11 +543,28 @@ SystemZTargetLowering::SystemZTargetLowering(const
TargetMachine &TM,
}
// Handle floating-point types.
+ if (!useSoftFloat()) {
+// Promote all f16 operations to float, with some exceptions below.
+for (unsigned Opc = 0; Opc < ISD::BUILTIN_
Author: Donát Nagy
Date: 2025-03-20T17:08:52+01:00
New Revision: 7c1f473524abe4d85af9ea390d3516848c9ba31e
URL:
https://github.com/llvm/llvm-project/commit/7c1f473524abe4d85af9ea390d3516848c9ba31e
DIFF:
https://github.com/llvm/llvm-project/commit/7c1f473524abe4d85af9ea390d3516848c9ba31e.diff
LO
Author: Kazu Hirata
Date: 2025-03-20T09:09:57-07:00
New Revision: c38ef58557e26394e330f6ba16ff71b492cf50bb
URL:
https://github.com/llvm/llvm-project/commit/c38ef58557e26394e330f6ba16ff71b492cf50bb
DIFF:
https://github.com/llvm/llvm-project/commit/c38ef58557e26394e330f6ba16ff71b492cf50bb.diff
L
https://github.com/kazutakahirata closed
https://github.com/llvm/llvm-project/pull/132142
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
erichkeane wrote:
> > The more I think about it, the more I think that we should modify the
> > warning to only happen on EXPLICIT qualifiers. So:
> > ```
> > struct Base{};
> > using CBase = const Base;
> >
> > struct D1 : const Base {}; // DOES warn
> > struct D2 : CBase{}; // a DIFFERENT war
@@ -548,11 +543,28 @@ SystemZTargetLowering::SystemZTargetLowering(const
TargetMachine &TM,
}
// Handle floating-point types.
+ if (!useSoftFloat()) {
+// Promote all f16 operations to float, with some exceptions below.
+for (unsigned Opc = 0; Opc < ISD::BUILTIN_
https://github.com/frasercrmck created
https://github.com/llvm/llvm-project/pull/132213
Similar to work done in 82912fd6, this commit re-licenses both the
gen_convert.py script, and the it generates.
It previously possessed an MIT license, with three additional individual
copyrights. The file
https://github.com/balazske created
https://github.com/llvm/llvm-project/pull/132242
There can be concerns about the usefulness of this check but for some code it
can be useful.
From e3064b600ea726ab7b3dea054e9f11e1ce028297 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bal=C3=A1zs=20K=C3=A9ri?=
Da
https://github.com/V-FEXrt approved this pull request.
https://github.com/llvm/llvm-project/pull/131032
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ilovepi wrote:
hey, sorry, I ended up landing
https://github.com/llvm/llvm-project/pull/131939. There are two reasons: 1) I
really wanted to fix that crash ASAP. 2) I made the mistake of stacking other
patches on top of it with graphite, and it turns out it isn't easy to reorder
them. As a re
https://github.com/bogner updated
https://github.com/llvm/llvm-project/pull/130231
>From bf5e5b4b1060f51d37b05c905b4327a40316f158 Mon Sep 17 00:00:00 2001
From: Justin Bogner
Date: Thu, 6 Mar 2025 17:50:12 -0800
Subject: [PATCH] [HLSL] Buffer handle globals should not be constants
If these are
@@ -0,0 +1,102 @@
+//===-- CGBuiltin.h - LLVM CodeGen wrappers for llvm::Value* --*- C++
-*-===//
+//
+// 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:
@@ -0,0 +1,102 @@
+//===-- CGBuiltin.h - LLVM CodeGen wrappers for llvm::Value* --*- C++
-*-===//
+//
+// 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:
@@ -0,0 +1,102 @@
+//===-- CGBuiltin.h - LLVM CodeGen wrappers for llvm::Value* --*- C++
-*-===//
+//
+// 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:
@@ -19681,6 +19681,21 @@ Value *CodeGenFunction::EmitHLSLBuiltinExpr(unsigned
BuiltinID,
getDotProductIntrinsic(CGM.getHLSLRuntime(), VecTy0->getElementType()),
ArrayRef{Op0, Op1}, nullptr, "hlsl.dot");
}
+ case Builtin::BI__builtin_hlsl_dot2add: {
+llvm
1 - 100 of 345 matches
Mail list logo
