efriedma-quic wrote:
This patch appears to do two things:
- Add a "default align" attribute, which instructions the backend to use some
unspecified "default" alignment for the function in question.
- Tells the frontend to apply this attribute specifically to "cold" functions.
This is basically
@@ -1363,6 +1367,8 @@ static void __init_cpu_features_constructor(unsigned long
hwcap,
setCPUFeature(FEAT_SME_I64);
if (hwcap2 & HWCAP2_SME_F64F64)
setCPUFeature(FEAT_SME_F64);
+ if (hwcap2 & HWCAP2_SME_FA64)
+setCPUFeature(FEAT_SME_FA64);
ilinp
yxsamliu wrote:
> > @ldionne - Can you take a look if that would have unintended consequences
> > for libc++?
>
> Honestly, I don't know. I don't know CUDA nearly well enough to understand
> all the implications here. All I know is that this seems to be a pretty
> significant "fork" of C++ in
@@ -0,0 +1,163 @@
+//===--- APINotesManager.h - Manage API Notes Files -*- 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: Ap
@@ -0,0 +1,469 @@
+//===--- APINotesManager.cpp - Manage API Notes Files
-===//
+//
+// 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
@@ -322,6 +322,90 @@ static Attr *handleUnlikely(Sema &S, Stmt *St, const
ParsedAttr &A,
return ::new (S.Context) UnlikelyAttr(S.Context, A);
}
+CodeAlignAttr *Sema::BuildCodeAlignAttr(const AttributeCommonInfo &CI,
+Expr *E) {
+ if
bwendling wrote:
@kees interesting difference between `0` and `1` in `__bdos()`. You probably
know about it, but I was surprised: https://godbolt.org/z/KTeqanjKf
https://github.com/llvm/llvm-project/pull/71877
___
cfe-commits mailing list
cfe-commits@
https://github.com/augusto2112 updated
https://github.com/llvm/llvm-project/pull/72011
>From 8cebb68070de258e6f581e83c3b0541087f53570 Mon Sep 17 00:00:00 2001
From: Augusto Noronha
Date: Mon, 13 Nov 2023 09:48:00 -0800
Subject: [PATCH] [DebugInfo][CGDebugInfo] Add RunTimeLang to more DIBuilder
Author: Augusto Noronha
Date: 2023-11-15T12:46:06-08:00
New Revision: d0ae2391897033c50225a20fd3024816dffd80b6
URL:
https://github.com/llvm/llvm-project/commit/d0ae2391897033c50225a20fd3024816dffd80b6
DIFF:
https://github.com/llvm/llvm-project/commit/d0ae2391897033c50225a20fd3024816dffd80b6.dif
https://github.com/augusto2112 closed
https://github.com/llvm/llvm-project/pull/72011
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -11,557 +11,614 @@
namespace hlsl {
-__attribute__((availability(shadermodel, introduced = 6.0)))
-__attribute__((clang_builtin_alias(__builtin_hlsl_wave_active_count_bits)))
uint
-WaveActiveCountBits(bool bBit);
+// Note: Functions in this file are sorted alphabetically,
https://github.com/smanna12 edited
https://github.com/llvm/llvm-project/pull/70762
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smanna12 edited
https://github.com/llvm/llvm-project/pull/70762
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
kees wrote:
Yeah, this is the "compiler doesn't know if pointer points into an array of
structs or not" that has driven me crazy for years. But we can now reliably
disambiguate this for structs that end with a flexible array member (or future
pointers marked with `__single`). It's been a long
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/66702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
banach-space wrote:
[nit] Dynamic linker will only be used with shared objects, but this file also
tests `static`. So the name is a bit confusing. But I don't have any great
suggestion myself. Perhaps update the comment to clarify that this test is
specifical
https://github.com/banach-space approved this pull request.
Thanks for seeing this through, that's much appreciated!
https://github.com/llvm/llvm-project/pull/66702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
@@ -208,6 +208,11 @@ New check aliases
Changes in existing checks
^^
+- Improved :doc:`bugprone-assert-side-effect
+ ` check to report usage of
+ non-const `<<` and `>>` operators in assertions and fixed some
false-positives
PiotrZSL
https://github.com/PiotrZSL approved this pull request.
LGTM, rebase code before merging
https://github.com/llvm/llvm-project/pull/71974
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
haoNoQ wrote:
Hmm, it really worries me that `MallocChecker` is setting a return value
outside of `evalCall()`. This can easily lead to conflicts if multiple checkers
try to do this: `evalCall()` is protected from conflicts (the engine asserts
that at most one checker evaluates each call) but
@@ -266,13 +266,18 @@ void CheckUseZeroAllocated1(void) {
}
char CheckUseZeroAllocated2(void) {
+ // FIXME: The return value of `alloca()` is modeled with `AllocaRegion`
+ // instead of `SymbolicRegion`, so the current implementation of
+ // `MallocChecker::checkUseZeroAllo
@@ -322,6 +322,90 @@ static Attr *handleUnlikely(Sema &S, Stmt *St, const
ParsedAttr &A,
return ::new (S.Context) UnlikelyAttr(S.Context, A);
}
+CodeAlignAttr *Sema::BuildCodeAlignAttr(const AttributeCommonInfo &CI,
+Expr *E) {
+ if
@@ -322,6 +322,90 @@ static Attr *handleUnlikely(Sema &S, Stmt *St, const
ParsedAttr &A,
return ::new (S.Context) UnlikelyAttr(S.Context, A);
}
+CodeAlignAttr *Sema::BuildCodeAlignAttr(const AttributeCommonInfo &CI,
+Expr *E) {
+ if
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jthackray updated
https://github.com/llvm/llvm-project/pull/72395
>From 07b24207d100ac7d5deac76543c01710b8cab79e Mon Sep 17 00:00:00 2001
From: Jonathan Thackray
Date: Fri, 10 Nov 2023 15:37:08 +
Subject: [PATCH] [AArch64] Add support for Cortex-A520, Cortex-A720 and
Cor
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 c70f6fc4f4c33656b2048e37c287d5c811f413b2
07b24207d100ac7d5deac76543c01710b8cab79e --
https://github.com/schenker updated
https://github.com/llvm/llvm-project/pull/71974
>From dabfdee1a982000605e4b33930ba433c63d1684f Mon Sep 17 00:00:00 2001
From: Thomas Schenker
Date: Fri, 10 Nov 2023 18:58:26 +0100
Subject: [PATCH 1/5] [clang-tidy] bugprone-assert-side-effect non-const
operat
https://github.com/smanna12 updated
https://github.com/llvm/llvm-project/pull/70762
>From 93d46d40f46663cfa30fc01da965887508684e25 Mon Sep 17 00:00:00 2001
From: "Manna, Soumi"
Date: Mon, 30 Oct 2023 21:41:00 -0700
Subject: [PATCH 01/25] [clang] Add support for new loop attribute
[[clang::code
@@ -322,6 +322,90 @@ static Attr *handleUnlikely(Sema &S, Stmt *St, const
ParsedAttr &A,
return ::new (S.Context) UnlikelyAttr(S.Context, A);
}
+CodeAlignAttr *Sema::BuildCodeAlignAttr(const AttributeCommonInfo &CI,
+Expr *E) {
+ if
https://github.com/schenker updated
https://github.com/llvm/llvm-project/pull/71974
>From 1f6e70ef97ba1bf90c829c212c6c1e09be4961f4 Mon Sep 17 00:00:00 2001
From: Thomas Schenker
Date: Fri, 10 Nov 2023 18:58:26 +0100
Subject: [PATCH 1/5] [clang-tidy] bugprone-assert-side-effect non-const
operat
@@ -322,6 +322,90 @@ static Attr *handleUnlikely(Sema &S, Stmt *St, const
ParsedAttr &A,
return ::new (S.Context) UnlikelyAttr(S.Context, A);
}
+CodeAlignAttr *Sema::BuildCodeAlignAttr(const AttributeCommonInfo &CI,
+Expr *E) {
+ if
@@ -322,6 +322,90 @@ static Attr *handleUnlikely(Sema &S, Stmt *St, const
ParsedAttr &A,
return ::new (S.Context) UnlikelyAttr(S.Context, A);
}
+CodeAlignAttr *Sema::BuildCodeAlignAttr(const AttributeCommonInfo &CI,
+Expr *E) {
+ if
@@ -322,6 +322,71 @@ static Attr *handleUnlikely(Sema &S, Stmt *St, const
ParsedAttr &A,
return ::new (S.Context) UnlikelyAttr(S.Context, A);
}
+CodeAlignAttr *Sema::BuildCodeAlignAttr(const AttributeCommonInfo &CI,
+Expr *E) {
+ if
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/72442
Summary:
Currently the linker wrapper strictly assigns a single input binary to a
single link job based off of its input architecture. This is not
sufficient to implement the AMDGPU target ID correctly as this cou
llvmbot wrote:
@llvm/pr-subscribers-llvm-binary-utilities
Author: Joseph Huber (jhuber6)
Changes
Summary:
Currently the linker wrapper strictly assigns a single input binary to a
single link job based off of its input architecture. This is not
sufficient to implement the AMDGPU target ID c
https://github.com/smanna12 updated
https://github.com/llvm/llvm-project/pull/70762
>From 93d46d40f46663cfa30fc01da965887508684e25 Mon Sep 17 00:00:00 2001
From: "Manna, Soumi"
Date: Mon, 30 Oct 2023 21:41:00 -0700
Subject: [PATCH 01/26] [clang] Add support for new loop attribute
[[clang::code
rjmccall wrote:
I agree with the Sema/AST-level LGTM (but also don't feel comfortable approving
the driver changes)
https://github.com/llvm/llvm-project/pull/71148
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
dyung wrote:
Hi @Michael137, we are seeing a failure in one of our internal tests that I
bisected back to this change. Consider the following code:
```C++
struct X
{
static const int constant = 1;
int x;
X() { x = constant; }
};
const int X::constant;
int main()
{
X x;
x.x
@@ -125,9 +125,9 @@
// MS-TYPEMETADATA: comdat($"??_7B@@6B0@@"), !type [[B8:![0-9]+]]
// MS-TYPEMETADATA: comdat($"??_7B@@6BA@@@"), !type [[A8]]
// MS-TYPEMETADATA: comdat($"??_7C@@6B@"), !type [[A8]]
-// MS-TYPEMETADATA: comdat($"??_7D@?A0x{{[^@]*}}@@6BB@@@"), !type [[B8]],
!
Michael137 wrote:
> Hi @Michael137, we are seeing a failure in one of our internal tests that I
> bisected back to this change. Consider the following code:
>
> ```c++
> struct X
> {
> static const int constant = 1;
> int x;
>
> X() { x = constant; }
> };
> const int X::constant;
>
Author: Amara Emerson
Date: 2023-11-15T14:12:52-08:00
New Revision: 250d9c86c201799755611c425ce6e02fb5867716
URL:
https://github.com/llvm/llvm-project/commit/250d9c86c201799755611c425ce6e02fb5867716
DIFF:
https://github.com/llvm/llvm-project/commit/250d9c86c201799755611c425ce6e02fb5867716.diff
dyung wrote:
> > Hi @Michael137, we are seeing a failure in one of our internal tests that I
> > bisected back to this change. Consider the following code:
> > ```c++
> > struct X
> > {
> > static const int constant = 1;
> > int x;
> >
> > X() { x = constant; }
> > };
> > const int
pogo59 wrote:
The member is const with an initializer in-class. How is the constant value not
available for the definition?
https://github.com/llvm/llvm-project/pull/71780
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
Michael137 wrote:
> The member is const with an initializer in-class. How is the constant value
> not available for the definition?
Right, it is available, we just don't attach it if we have a location for it.
Don't see why we couldn't put it on the definition if we have the constant on
hand
https://github.com/compnerd approved this pull request.
Some minor comments left to address about comments, but the rest LGTM.
https://github.com/llvm/llvm-project/pull/72389
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.or
rjmccall wrote:
First off, the change here actually applies to all over-aligned empty structs,
not just to those with aligned bit-fields. Maybe we can say that aligned
zero-width bit-fields are ill-formed, but I don't think we can say that all
aligned empty classes are ill-formed, among other
Author: Owen Pan
Date: 2023-11-15T14:28:37-08:00
New Revision: b04664be6f484551ba34e5e34c511e77d5af709a
URL:
https://github.com/llvm/llvm-project/commit/b04664be6f484551ba34e5e34c511e77d5af709a
DIFF:
https://github.com/llvm/llvm-project/commit/b04664be6f484551ba34e5e34c511e77d5af709a.diff
LOG:
https://github.com/owenca closed https://github.com/llvm/llvm-project/pull/72251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Owen Pan
Date: 2023-11-15T14:31:30-08:00
New Revision: eaff083035c86e32bd220fef5a2fab47117b70c1
URL:
https://github.com/llvm/llvm-project/commit/eaff083035c86e32bd220fef5a2fab47117b70c1
DIFF:
https://github.com/llvm/llvm-project/commit/eaff083035c86e32bd220fef5a2fab47117b70c1.diff
LOG:
https://github.com/owenca closed https://github.com/llvm/llvm-project/pull/72336
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
Oh, the [Apple AArch64 calling
convention](https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Pass-arguments-to-functions-correctly)
diverges from AAPCS and ignores empty classes as parameters. We appear to
consider this an empty class regar
https://github.com/jyu2-git updated
https://github.com/llvm/llvm-project/pull/71748
>From 3313aca0622da3882a9e5bf304b89f28fecce7fe Mon Sep 17 00:00:00 2001
From: Jennifer Yu
Date: Mon, 6 Nov 2023 20:51:39 -0800
Subject: [PATCH 1/4] [SEH] Fix assertin when return scalar value from __try
block.
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/69493
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,11 @@
+; RUN: opt < %s -passes=instrprof -profile-correlate=binary -S | FileCheck %s
ZequanWu wrote:
Moved the test to `coverage.ll`
https://github.com/llvm/llvm-project/pull/69493
___
cfe-commits mailing li
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping -emit-llvm
-o - %s | FileCheck %s
+// RUN: %clang_cc1 -mllvm -profile-correlate=binary -fprofile-instrument=clang
-fcoverage-mapping -emit-llvm -o - %s | FileCheck %s
--check-prefix=BIN-CORRELATE
@@ -0,0 +1,46 @@
+// REQUIRES: linux || windows
ZequanWu wrote:
I think lld is not require, removed `-fuse-ld=lld`.
https://github.com/llvm/llvm-project/pull/69493
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
@@ -1829,6 +1833,22 @@ void CoverageMappingModuleGen::emit() {
llvm::GlobalValue::InternalLinkage, NamesArrVal,
llvm::getCoverageUnusedNamesVarName());
}
+ const StringRef VarName(INSTR_PROF_QUOTE(INSTR_PROF_RAW_VERSI
@@ -46,14 +73,38 @@ const char *InstrProfCorrelator::NumCountersAttributeName =
"Num Counters";
llvm::Expected>
InstrProfCorrelator::Context::get(std::unique_ptr Buffer,
- const object::ObjectFile &Obj) {
+ con
https://github.com/ZequanWu commented:
> "binary" is ambiguous. I wonder whether object file correlation is better.
> llvm-symbolizer has an option --obj=xxx.
llvm-symbolizer's `--obj` could take an pre-linking object file. But here we
need to take post-linked binary for merging.
https://gith
@@ -1331,6 +1336,18 @@ static int merge_main(int argc, const char *argv[]) {
"(default: 1)"));
cl::ParseCommandLineOptions(argc, argv, "LLVM profile data merger\n");
+ if (!DebugInfoFilename.empty() && !BinaryFilename.empty()) {
+exitWithError("Expect
@@ -1331,6 +1336,18 @@ static int merge_main(int argc, const char *argv[]) {
"(default: 1)"));
cl::ParseCommandLineOptions(argc, argv, "LLVM profile data merger\n");
+ if (!DebugInfoFilename.empty() && !BinaryFilename.empty()) {
+exitWithError("Expect
@@ -1341,20 +1344,26 @@ void
InstrProfiling::createDataVariable(InstrProfCntrInstBase *Inc,
}
auto *Data =
new GlobalVariable(*M, DataTy, false, Linkage, nullptr, DataVarName);
- // Reference the counter variable with a label difference (link-time
- // constant).
-
@@ -195,8 +195,14 @@ OPTIONS
.. option:: --debug-info=
Specify the executable or ``.dSYM`` that contains debug info for the raw
profile.
- When ``-debug-info-correlate`` was used for instrumentation, use this option
- to correlate the raw profile.
+ When ``-profile-correlate
@@ -0,0 +1,46 @@
+// REQUIRES: linux || windows
+// Default
+// RUN: %clang -o %t.normal -fprofile-instr-generate -fcoverage-mapping
-fuse-ld=lld %S/Inputs/instrprof-debug-info-correlate-main.cpp
%S/Inputs/instrprof-debug-info-correlate-foo.cpp
+// RUN: env LLVM_PROFILE_FILE=%t.
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.
LGTM
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D158824/new/
https://reviews.llvm.org/D158824
___
dyung wrote:
> > The member is const with an initializer in-class. How is the constant value
> > not available for the definition?
>
> Right, it is available, we just don't attach it if we have a location for it.
> Don't see why we couldn't put it on the definition if we have the constant on
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/69493
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pogo59 wrote:
I think it is a valuable bit of information for the debugger, to know the
constant value without having to read it from memory. I think we should emit
both the location and the value.
https://github.com/llvm/llvm-project/pull/71780
___
ronlieb wrote:
thanks for the fix, working great now.
https://github.com/llvm/llvm-project/pull/72126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -12,27 +12,78 @@
#ifndef LLVM_ANALYSIS_INDIRECTCALLVISITOR_H
#define LLVM_ANALYSIS_INDIRECTCALLVISITOR_H
+#include "llvm/ADT/SetVector.h"
#include "llvm/IR/InstVisitor.h"
#include
namespace llvm {
-// Visitor class that finds all indirect call.
+// Visitor class that
@@ -490,6 +591,23 @@ Error InstrProfSymtab::addFuncWithName(Function &F,
StringRef PGOFuncName) {
return Error::success();
}
+uint64_t InstrProfSymtab::getVTableHashFromAddress(uint64_t Address) {
+ finalizeSymtab();
+ auto It = lower_bound(
+ VTableAddrRangeToMD5Map
@@ -1441,6 +1531,9 @@ void OverlapStats::dump(raw_fd_ostream &OS) const {
case IPVK_MemOPSize:
strncpy(ProfileKindName, "MemOP", 19);
break;
+case IPVK_VTableTarget:
+ strncpy(ProfileKindName, "VTable", 6);
minglotus-6 wrote:
thanks fo
https://github.com/minglotus-6 edited
https://github.com/llvm/llvm-project/pull/66825
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/minglotus-6 commented:
thanks for the reviews and discussions!
This PR currently merged upstream main at a commit on Nov 9th. I started to
have local changes after that, so refrained from another merge. Will do that
separately.
https://github.com/llvm/llvm-project/pull/6682
@@ -123,19 +137,29 @@ static int needsCounterPadding(void) {
COMPILER_RT_VISIBILITY
void __llvm_profile_get_padding_sizes_for_counters(
uint64_t DataSize, uint64_t CountersSize, uint64_t NumBitmapBytes,
-uint64_t NamesSize, uint64_t *PaddingBytesBeforeCounters,
-uin
@@ -275,18 +282,28 @@ lprofWriteDataImpl(ProfDataWriter *Writer, const
__llvm_profile_data *DataBegin,
const uint64_t NumBitmapBytes =
__llvm_profile_get_num_bitmap_bytes(BitmapBegin, BitmapEnd);
const uint64_t NamesSize = __llvm_profile_get_name_size(NamesBegin,
Na
@@ -489,30 +520,66 @@ class InstrProfSymtab {
/// \p IterRange. This interface is used by IndexedProfReader.
template Error create(const NameIterRange
&IterRange);
- /// Update the symtab by adding \p FuncName to the table. This interface
- /// is used by the raw and t
@@ -453,11 +471,94 @@ Error InstrProfSymtab::create(Module &M, bool InLTO) {
if (Error E = addFuncWithName(F, getPGOFuncName(F, InLTO)))
return E;
}
+
+ SmallVector Types;
+ for (GlobalVariable &G : M.globals()) {
+if (!G.hasName())
+ continue;
+Types
@@ -1070,8 +1084,138 @@ void InstrProfiling::maybeSetComdat(GlobalVariable *GV,
Function *Fn,
GV->setLinkage(GlobalValue::InternalLinkage);
}
-GlobalVariable *InstrProfiling::setupProfileSection(InstrProfInstBase *Inc,
-
@@ -1070,8 +1084,138 @@ void InstrProfiling::maybeSetComdat(GlobalVariable *GV,
Function *Fn,
GV->setLinkage(GlobalValue::InternalLinkage);
}
-GlobalVariable *InstrProfiling::setupProfileSection(InstrProfInstBase *Inc,
-
https://github.com/rjmccall requested changes to this pull request.
Marking as changes requested so that this doesn't get committed.
https://github.com/llvm/llvm-project/pull/72197
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.l
Michael137 wrote:
> So I guess what you are saying in this case is that it is expected and the
> value is at the location indicated by the DW_AT_location value? As long as
> the value is still available I suppose that is fine then and the test just
> needs updating.
Yup that's exactly right.
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/69493
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Amara Emerson
Date: 2023-11-15T15:22:12-08:00
New Revision: d7ce58048a586157e709e2dca5f33dd4f41b087d
URL:
https://github.com/llvm/llvm-project/commit/d7ce58048a586157e709e2dca5f33dd4f41b087d
DIFF:
https://github.com/llvm/llvm-project/commit/d7ce58048a586157e709e2dca5f33dd4f41b087d.diff
@@ -172,3 +172,32 @@
// RUN: --check-prefix=CHECK-LIBCXX-STDLIB-UNSPECIFIED %s
// CHECK-LIBCXX-STDLIB-UNSPECIFIED: "-cc1"
// CHECK-LIBCXX-STDLIB-UNSPECIFIED: "-internal-isystem"
"[[SYSROOT]]/usr/include/c++/v1"
+
+// --
@@ -172,3 +172,32 @@
// RUN: --check-prefix=CHECK-LIBCXX-STDLIB-UNSPECIFIED %s
// CHECK-LIBCXX-STDLIB-UNSPECIFIED: "-cc1"
// CHECK-LIBCXX-STDLIB-UNSPECIFIED: "-internal-isystem"
"[[SYSROOT]]/usr/include/c++/v1"
+
+// --
https://github.com/bd1976bris created
https://github.com/llvm/llvm-project/pull/72452
https://reviews.llvm.org/D128482 regressed certain cases of VTT emission which
are no longer hidden with -fvisibility=hidden.
Fix this regression by marking both declarations and definitions.
Fixes [clang co
Author: Ben Shi
Date: 2023-11-16T07:36:57+08:00
New Revision: d5af076a99b625b4caf0b72b97ee6c88af6f4ba4
URL:
https://github.com/llvm/llvm-project/commit/d5af076a99b625b4caf0b72b97ee6c88af6f4ba4
DIFF:
https://github.com/llvm/llvm-project/commit/d5af076a99b625b4caf0b72b97ee6c88af6f4ba4.diff
LOG:
https://github.com/benshi001 closed
https://github.com/llvm/llvm-project/pull/71518
___
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: bd1976bris (bd1976bris)
Changes
https://reviews.llvm.org/D128482 regressed certain cases of VTT emission which
are no longer hidden with -fvisibility=hidden.
Fix this regression by marking both declarations and definitions.
Fixes [clang
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: bd1976bris (bd1976bris)
Changes
https://reviews.llvm.org/D128482 regressed certain cases of VTT emission which
are no longer hidden with -fvisibility=hidden.
Fix this regression by marking both declarations and definitions.
Fixes
Author: Ben Shi
Date: 2023-11-16T07:37:33+08:00
New Revision: 917a550f4d7aaa79b04ed8998a45695a29f0f748
URL:
https://github.com/llvm/llvm-project/commit/917a550f4d7aaa79b04ed8998a45695a29f0f748
DIFF:
https://github.com/llvm/llvm-project/commit/917a550f4d7aaa79b04ed8998a45695a29f0f748.diff
LOG:
https://github.com/benshi001 closed
https://github.com/llvm/llvm-project/pull/72358
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bd1976bris updated
https://github.com/llvm/llvm-project/pull/72452
>From f6e400224b3a90b4ec47bce2212a8e760b0fe9d8 Mon Sep 17 00:00:00 2001
From: Ben Dunbobbin
Date: Wed, 15 Nov 2023 23:09:41 +
Subject: [PATCH] [clang codegen] Add dso_local/hidden/etc. markings to VTT
def
https://github.com/ributzka updated
https://github.com/llvm/llvm-project/pull/71985
>From a6a9ebe0f8077889b6cb4bafd75c9eb66a823bc4 Mon Sep 17 00:00:00 2001
From: Juergen Ributzka
Date: Fri, 10 Nov 2023 12:39:16 -0800
Subject: [PATCH 1/2] [clang] Make `-fvisibility={}` and `-ftype-visibility={}`
ldionne wrote:
This seems reasonable. I read the discussion about the size of the member but I
think this is unlikely to change much -- plus I think the compiler should be
able to diagnose in case the string becomes smaller and we'd be copying from a
past-the-end location into the data structu
Author: Michael Kenzel
Date: 2023-11-15T18:41:53-05:00
New Revision: b7a249d26fe61432050df470d23bdea417fda574
URL:
https://github.com/llvm/llvm-project/commit/b7a249d26fe61432050df470d23bdea417fda574
DIFF:
https://github.com/llvm/llvm-project/commit/b7a249d26fe61432050df470d23bdea417fda574.diff
https://github.com/ldionne closed
https://github.com/llvm/llvm-project/pull/72043
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/PiJoules updated
https://github.com/llvm/llvm-project/pull/68344
>From 1eb1638a12c619febf1fe9830f34e51a56d4c20e Mon Sep 17 00:00:00 2001
From: Leonard Chan
Date: Thu, 5 Oct 2023 19:19:47 +
Subject: [PATCH] [clang] Ensure fixed point conversions work in C++
---
clang/inc
https://github.com/nicovank updated
https://github.com/llvm/llvm-project/pull/72385
>From 96e00378116ca5fbfad6edb220e86326dc4f9897 Mon Sep 17 00:00:00 2001
From: Nicolas van Kempen
Date: Wed, 15 Nov 2023 01:13:10 -0800
Subject: [PATCH] [clang-tidy] Add new performance-use-starts-ends-with check
401 - 500 of 594 matches
Mail list logo
