rnk wrote:
To be clear, you can repro the issue with the test case you have, just add
`-fsanitize=address` to flags to repro.
https://github.com/llvm/llvm-project/pull/90310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.or
rnk wrote:
Are we sure we want this behavior? Demangling is really expensive. A user
noticed a significant (10%) compile time regression from this change. We could
skip the demangling and do it offline. It's also worth pointing out that we
have to redo this work every time we optimize the same
rnk wrote:
I think I'll leave this change in and file an issue about it. A 10% compile
time regression with `-ftime-trace` isn't great, but it doesn't feel
revert-worthy.
https://github.com/llvm/llvm-project/pull/87626
___
cfe-commits mailing list
cf
Author: Reid Kleckner
Date: 2022-02-23T14:01:01-08:00
New Revision: cd37594c0374f287318d47818cc6d55496d3e9c0
URL:
https://github.com/llvm/llvm-project/commit/cd37594c0374f287318d47818cc6d55496d3e9c0
DIFF:
https://github.com/llvm/llvm-project/commit/cd37594c0374f287318d47818cc6d55496d3e9c0.diff
Author: Reid Kleckner
Date: 2022-02-23T14:07:04-08:00
New Revision: 1d1b089c5d503e2fc8697887411730105f66c774
URL:
https://github.com/llvm/llvm-project/commit/1d1b089c5d503e2fc8697887411730105f66c774
DIFF:
https://github.com/llvm/llvm-project/commit/1d1b089c5d503e2fc8697887411730105f66c774.diff
never
> type erased/put in a std::function or equivalent). Avoids assert/non-assert
> unused issues, having to maintain/update the list when the code changes and
> makes a capture live/dead/etc.
>
> On Wed, Feb 23, 2022 at 2:09 PM Reid Kleckner via cfe-commits <
> cfe-commits@lists.llvm.o
Author: Reid Kleckner
Date: 2021-04-26T18:32:50-07:00
New Revision: 6d78c38986fa0974ea0b37e66f8cb89b256f4e0d
URL:
https://github.com/llvm/llvm-project/commit/6d78c38986fa0974ea0b37e66f8cb89b256f4e0d
DIFF:
https://github.com/llvm/llvm-project/commit/6d78c38986fa0974ea0b37e66f8cb89b256f4e0d.diff
Author: Olivier Goffart
Date: 2021-05-07T13:27:59-07:00
New Revision: c4adc49a1c988e6ea8a340b6245525ef5599812c
URL:
https://github.com/llvm/llvm-project/commit/c4adc49a1c988e6ea8a340b6245525ef5599812c
DIFF:
https://github.com/llvm/llvm-project/commit/c4adc49a1c988e6ea8a340b6245525ef5599812c.dif
Author: Reid Kleckner
Date: 2021-01-07T11:14:18-08:00
New Revision: ad55d5c3f32f6598f8ac30b68f4961d82cdb1fed
URL:
https://github.com/llvm/llvm-project/commit/ad55d5c3f32f6598f8ac30b68f4961d82cdb1fed
DIFF:
https://github.com/llvm/llvm-project/commit/ad55d5c3f32f6598f8ac30b68f4961d82cdb1fed.diff
Author: Reid Kleckner
Date: 2021-01-19T11:15:02-08:00
New Revision: 6f69f2ed61ae805df496fc86ef22e7685573d556
URL:
https://github.com/llvm/llvm-project/commit/6f69f2ed61ae805df496fc86ef22e7685573d556
DIFF:
https://github.com/llvm/llvm-project/commit/6f69f2ed61ae805df496fc86ef22e7685573d556.diff
Author: Reid Kleckner
Date: 2021-01-19T11:15:02-08:00
New Revision: e678656625a3e2b6a5f2849f4a6f7612ceeaed07
URL:
https://github.com/llvm/llvm-project/commit/e678656625a3e2b6a5f2849f4a6f7612ceeaed07
DIFF:
https://github.com/llvm/llvm-project/commit/e678656625a3e2b6a5f2849f4a6f7612ceeaed07.diff
Author: Reid Kleckner
Date: 2021-10-08T15:43:56-07:00
New Revision: 955dc3449acd64c0505a3823aa93a6af38b00782
URL:
https://github.com/llvm/llvm-project/commit/955dc3449acd64c0505a3823aa93a6af38b00782
DIFF:
https://github.com/llvm/llvm-project/commit/955dc3449acd64c0505a3823aa93a6af38b00782.diff
Author: Reid Kleckner
Date: 2021-08-23T15:56:29-07:00
New Revision: e42ce422a97876e5ecd1c845b12ec65f96f8a293
URL:
https://github.com/llvm/llvm-project/commit/e42ce422a97876e5ecd1c845b12ec65f96f8a293
DIFF:
https://github.com/llvm/llvm-project/commit/e42ce422a97876e5ecd1c845b12ec65f96f8a293.diff
Author: Reid Kleckner
Date: 2021-08-25T14:41:26-07:00
New Revision: db3d029fbe09925ea42a3279b1abb244fa547cff
URL:
https://github.com/llvm/llvm-project/commit/db3d029fbe09925ea42a3279b1abb244fa547cff
DIFF:
https://github.com/llvm/llvm-project/commit/db3d029fbe09925ea42a3279b1abb244fa547cff.diff
https://github.com/rnk approved this pull request.
Thanks for doing this!
https://github.com/llvm/llvm-project/pull/105821
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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
rnk wrote:
IIUC, this effectively removes all empty records from LLVM struct types. This
makes the IR less "pretty", but these subobjects are notionally empty and
consist of only padding bytes (i8 and i8 arrays) at the end of the day. I think
that's acceptable. + @rjmccall , does that sound go
https://github.com/rnk approved this pull request.
Thanks!
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
@@ -0,0 +1,67 @@
+//===-- clang/Support/Compiler.h - Compiler abstraction support -*- 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: Apa
@@ -0,0 +1,1013 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -Wstack-exhausted -verify
+
+class AClass {
+public:
+ AClass() {}
+ AClass &foo() { return *this; }
+};
+
+void test_bar() {
+ AClass a;
+ // expected-warning@* {{stack nearly exhausted; compilation time may suffer,
a
rnk wrote:
I would stick with `fms-compatibility` being the setting here rather than
plumbing the driver mode through. Over the years, many build systems have been
adapted to work with `clang[++]` and `cl` without going through clang-cl.
https://github.com/llvm/llvm-project/pull/105738
___
https://github.com/rnk commented:
Thanks!
https://github.com/llvm/llvm-project/pull/110986
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1430,6 +1434,10 @@ bool Interpret(InterpState &S, APValue &Result) {
}
}
}
+// https://github.com/llvm/llvm-project/issues/102513
+#if defined(_MSC_VER)
rnk wrote:
Please make the ifdef conditions match, or define your own macro like
DEOPTIMIZE_SWIT
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/110986
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/115099
>From e1331b2c00db0cdff09345b36fd484f2269ee1cc Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Tue, 5 Nov 2024 16:05:53 -0800
Subject: [PATCH 1/2] [Win/X86] Make _m_prefetch[w] builtins to avoid winnt.h
conflicts
@@ -1182,8 +1187,13 @@
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
const bool IsCtxProfUse =
!UseCtxProfile.empty() && Phase == ThinOrFullLTOPhase::ThinLTOPreLink;
+ // Enable cold function coverage instrumentation if
+ // InstrumentColdF
rnk wrote:
We can adjust the rules around language linkage if we like, but the main reason
we implement builtins this way is to support the MSVC intrinsic model, which is
to declare extern "C" functions and mark them with `#pragma intrinsic(NAME)`
like so:
```
extern "C" void _m_prefetchw(vola
@@ -12658,10 +12658,10 @@ This instruction requires several arguments:
the return value of the callee is returned to the caller's caller, even
if a void return type is in use.
- Both markers imply that the callee does not access allocas from the caller.
- The `
https://github.com/rnk commented:
Thanks for prioritizing this! I have triaged many internal issues about this.
https://github.com/llvm/llvm-project/pull/109943
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/109943
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -5706,6 +5707,27 @@ void ASTWriter::WriteDeclAndTypes(ASTContext &Context) {
Stream.EmitRecord(DELAYED_NAMESPACE_LEXICAL_VISIBLE_RECORD,
DelayedNamespaceRecord);
+ if (!FunctionToLambdasMap.empty()) {
+// TODO: on disk hash table for function
@@ -5713,8 +5713,7 @@ void ASTWriter::WriteDeclAndTypes(ASTContext &Context) {
// efficent becuase it allows lazy deserialization.
RecordData FunctionToLambdasMapRecord;
for (const auto &Pair : FunctionToLambdasMap) {
rnk wrote:
This is now an iter
@@ -5706,6 +5707,27 @@ void ASTWriter::WriteDeclAndTypes(ASTContext &Context) {
Stream.EmitRecord(DELAYED_NAMESPACE_LEXICAL_VISIBLE_RECORD,
DelayedNamespaceRecord);
+ if (!FunctionToLambdasMap.empty()) {
+// TODO: on disk hash table for function
rnk wrote:
By the way, the x86 backend also miscompiles test cases like this:
```
struct ByVal { int large[5]; };
void f(ByVal a, ByVal b);
void g(ByVal a, ByVal b) {
[[clang::musttail]] f(b, a);
}
```
I have an internal issue assigned to @aeubanks tracking that. I may have
reported it upstre
rnk wrote:
> If the function-local types should not be ODR-uniqued, then dropping the
> identifier field sounds correct.
I can't speak to the complexities of the alternative, but I'm immediately
suspicious of this direction. We have stable manglings for static locals in
inline functions and s
rnk wrote:
> Perhaps a worthwhile direction is separating DISubprograms into abstract and
> definition portions, much like DWARF does, which would allow us to put these
> types into the declaration and have a well defined scope hierarchy: types
> that get uniqued refer to the abstract-DISubpro
rnk wrote:
> Is there a plan for maintaining these annotations long-term? Like, should
> there be a pre-commit action to verify that all the annotations are
> up-to-date?
pre-commit actions are expensive, but I think we could afford to do something
here. It is not hard to set up a DLL build o
@@ -439,8 +439,16 @@ AST_MATCHER(ArraySubscriptExpr, isSafeArraySubscript) {
dyn_cast(Node.getBase()->IgnoreParenImpCasts());
rnk wrote:
There's a FIXME above about refactoring Sema::CheckArrayAccess to avoid
duplication, and I'm trying to decide if that
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/117370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk commented:
I think there's a policy question here of how much trust we want to put into
the type system. Clearly, we've already put some trust into it to reduce false
positives, but we could decide to trust any old constant array type bounds, and
that would be a good cod
@@ -463,6 +471,13 @@ AST_MATCHER(ArraySubscriptExpr, isSafeArraySubscript) {
return true;
rnk wrote:
I think getting the integer constant expr is more general, we can remove the
IntegerLiteral test here, and if all tests pass, I would consider it
functio
rnk wrote:
I think it makes sense to focus on Saleem's use case, which, perhaps to
translate it into Posix-ecosystem terms, is to create a single Clang DSO
(similar to llvm-dylib or whatever we call it) that all the affiliated monorepo
Clang tools use (clang-tidy, clang-rename, clang-format, c
https://github.com/rnk commented:
This is an LLVM code change, not a clang code change. It's an important
principle that we test LLVM at the smallest reasonable granularity. Can you
replace the clang test with an IR test? I'm sure we already have existing IR
carrying existing sections, we just
@@ -19001,9 +19001,9 @@ void Sema::ActOnFields(Scope *S, SourceLocation RecLoc,
Decl *EnclosingDecl,
// Verify that all the fields are okay.
SmallVector RecFields;
-
+ std::optional PreviousField;
rnk wrote:
It doesn't seem idiomatic to use an optional
@@ -19213,6 +19213,29 @@ void Sema::ActOnFields(Scope *S, SourceLocation
RecLoc, Decl *EnclosingDecl,
if (Record && FD->getType().isVolatileQualified())
Record->setHasVolatileMember(true);
+auto IsNonDependentBitField = [](const FieldDecl *FD) {
+ if (!FD->
@@ -19213,6 +19213,29 @@ void Sema::ActOnFields(Scope *S, SourceLocation
RecLoc, Decl *EnclosingDecl,
if (Record && FD->getType().isVolatileQualified())
Record->setHasVolatileMember(true);
+auto IsNonDependentBitField = [](const FieldDecl *FD) {
+ if (!FD->
@@ -631,6 +631,7 @@ def Packed : DiagGroup<"packed", [PackedNonPod]>;
def PaddedBitField : DiagGroup<"padded-bitfield">;
def Padded : DiagGroup<"padded", [PaddedBitField]>;
def UnalignedAccess : DiagGroup<"unaligned-access">;
+def MSBitfieldCompatibility : DiagGroup<"ms-bitfiel
@@ -0,0 +1,180 @@
+
+// RUN: %clang_cc1 -fsyntax-only -Wms-bitfield-compatibility -verify -triple
armv8 -std=c++23 %s
+// RUN: %clang_cc1 -fsyntax-only -DMS_BITFIELDS -mms-bitfields
-verify=msbitfields -triple armv8-apple-macos10.15 -std=c++23 %s
+
+// msbitfields-no-diagnostics
@@ -631,6 +631,9 @@ Improvements to Clang's diagnostics
- Clang now diagnoses dangling references for C++20's parenthesized aggregate
initialization (#101957).
+- A new off-by-default warning ``-Wms-bitfield-compatibility`` has been added
to alert to cases where bit-field
-
@@ -6418,6 +6418,12 @@ def warn_signed_bitfield_enum_conversion : Warning<
InGroup, DefaultIgnore;
def note_change_bitfield_sign : Note<
"consider making the bitfield type %select{unsigned|signed}0">;
+def warn_ms_bitfield_mismatched_storage_packing : Warning<
+ "bit-field
@@ -1834,6 +1834,14 @@ bool CompilerInvocation::ParseCodeGenArgs(CodeGenOptions
&Opts, ArgList &Args,
Opts.setInlining(CodeGenOptions::NormalInlining);
}
+ // If we have specified -Og and have not explicitly set
-fno-extend-lifetimes,
+ // then default to -fextend-li
@@ -53,10 +53,8 @@ class OptTable {
public:
/// Entry for a single option instance in the option data table.
struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+
@@ -80,15 +78,56 @@ class OptTable {
const char *AliasArgs;
const char *Values;
-StringRef getName() const {
- unsigned PrefixLength = Prefixes.empty() ? 0 : Prefixes[0].size();
- return PrefixedName.drop_front(PrefixLength);
+bool hasNoPrefix() const
@@ -845,13 +845,14 @@ MemoryBufferRef
LinkerDriver::convertResToCOFF(ArrayRef mbs,
// Create OptTable
+#define OPTTABLE_STR_TABLE_CODE
rnk wrote:
Is it feasible to split out all the tool driver updates, like refactor all
these PREFIX definitions into the t
@@ -53,10 +53,8 @@ class OptTable {
public:
/// Entry for a single option instance in the option data table.
struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/115099
>From e5f485ad8000c296229794346fdd627b90e504d2 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Tue, 5 Nov 2024 16:05:53 -0800
Subject: [PATCH 1/7] [Win/X86] Make _m_prefetch[w] builtins to avoid winnt.h
conflicts
https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/115099
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/120534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
Thanks for optimizing the builtins! I feel like builtins have grown
significantly since adding RISC-V and ARM MVE intrinsics, and few people until
now have stopped to re-evaluate how we represent these things.
While I was watching these clearl
@@ -482,17 +488,42 @@ void clang::EmitClangBuiltins(const RecordKeeper
&Records, raw_ostream &OS) {
for (const auto *BuiltinRecord :
Records.getAllDerivedDefinitions("AtomicBuiltin"))
collectBuiltins(BuiltinRecord, Builtins);
-
unsigned NumAtomicBuiltins = Buil
@@ -146,8 +146,13 @@ let Attributes = [Const, NoThrow,
RequiredVectorWidth<256>], Features = "avx" in
// current formulation is based on what was easiest to recognize from the
// pre-TableGen version.
-let Features = "mmx", Attributes = [NoThrow, Const] in {
- def _mm_prefet
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/115099
>From e5f485ad8000c296229794346fdd627b90e504d2 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Tue, 5 Nov 2024 16:05:53 -0800
Subject: [PATCH 1/3] [Win/X86] Make _m_prefetch[w] builtins to avoid winnt.h
conflicts
https://github.com/rnk commented:
I had to rebase this over the table-gen-ification of the builtins, but I think
this is still relevant.
https://github.com/llvm/llvm-project/pull/115099
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
@@ -31,10 +31,13 @@
// All MMX instructions will be generated via builtins. Any MMX vector
// types (<1 x i64>, <2 x i32>, etc.) that aren't used by these builtins will
be
// expanded by the back-end.
+//
// FIXME: _mm_prefetch must be a built-in because it takes a compile-ti
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/115099
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/115099
>From e5f485ad8000c296229794346fdd627b90e504d2 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Tue, 5 Nov 2024 16:05:53 -0800
Subject: [PATCH 1/5] [Win/X86] Make _m_prefetch[w] builtins to avoid winnt.h
conflicts
@@ -2225,9 +2221,10 @@ _mm_storer_ps(float *__p, __m128 __a)
///be generated. \n
///_MM_HINT_T2: Move data using the T2 hint. The PREFETCHT2 instruction
will
///be generated.
-#define _mm_prefetch(a, sel) (__builtin_prefetch((const void *)(a), \
-
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/115099
>From e5f485ad8000c296229794346fdd627b90e504d2 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Tue, 5 Nov 2024 16:05:53 -0800
Subject: [PATCH 1/6] [Win/X86] Make _m_prefetch[w] builtins to avoid winnt.h
conflicts
rnk wrote:
> But one specific question: would you prefer me to land as a series of commits
> or a single squashed commit for the entire PR? I'm happy either way. My mild
> preference is to prefer the series of commits, but open to suggestions here.
I would land it as the six-patch stack in thi
@@ -74,7 +74,7 @@ static CCMangling getCallingConvMangling(const ASTContext
&Context,
if (FD->isMain() && FD->getNumParams() == 2)
return CCM_WasmMainArgcArgv;
- if (!Triple.isOSWindows() || !Triple.isX86())
+ if (!Triple.isOSWindowsOrUEFI() || !Triple.isX86()
@@ -5193,12 +5193,12 @@ bool Sema::CheckCallingConvAttr(const ParsedAttr
&Attrs, CallingConv &CC,
CC = CC_X86RegCall;
break;
case ParsedAttr::AT_MSABI:
-CC = Context.getTargetInfo().getTriple().isOSWindows() ? CC_C :
-
rnk wrote:
> The build is still broken (e.g.
> https://lab.llvm.org/buildbot/#/builders/63/builds/3861). I'll back it out.
Thank you for doing that. I missed all notifications because they got lost in
the storm of failures due to the mismatch between my local build and what was
on github.
ht
@@ -2949,15 +2950,34 @@ static void handleSectionAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
}
}
+static bool isValidCodeModelAttr(Sema &S, StringRef Str) {
+ if (S.Context.getTargetInfo().getTriple().isLoongArch()) {
+return Str == "normal" || Str == "medium" || St
rnk wrote:
I assume it is safe for all device side compilations to ignore this attribute.
Presumably device code uses fully general patterns to access global data that
could live in any shared object. Most device ISAs are virtual anyway, it's not
like they're going to use PC relative addressin
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/115099
>From e5f485ad8000c296229794346fdd627b90e504d2 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Tue, 5 Nov 2024 16:05:53 -0800
Subject: [PATCH 1/4] [Win/X86] Make _m_prefetch[w] builtins to avoid winnt.h
conflicts
@@ -146,8 +146,13 @@ let Attributes = [Const, NoThrow,
RequiredVectorWidth<256>], Features = "avx" in
// current formulation is based on what was easiest to recognize from the
// pre-TableGen version.
-let Features = "mmx", Attributes = [NoThrow, Const] in {
- def _mm_prefet
@@ -53,10 +53,8 @@ class OptTable {
public:
/// Entry for a single option instance in the option data table.
struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+
@@ -845,13 +845,14 @@ MemoryBufferRef
LinkerDriver::convertResToCOFF(ArrayRef mbs,
// Create OptTable
+#define OPTTABLE_STR_TABLE_CODE
rnk wrote:
I convinced myself this is not worth it. The changes to the
`PrecomputedOptTable` are hard to abstract away. I
https://github.com/rnk approved this pull request.
Thanks! I think this is ready to land.
https://github.com/llvm/llvm-project/pull/119198
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
@@ -112,6 +112,8 @@ class MCTargetOptions {
// Whether or not to use full register names on PowerPC.
bool PPCUseFullRegisterNames : 1;
+ bool PgoInstrumentation = false;
rnk wrote:
Target options like this don't play well with (thin)LTO , because they do
@@ -463,6 +463,13 @@ AST_MATCHER(ArraySubscriptExpr, isSafeArraySubscript) {
return true;
}
+ // Array index wasn't an integer literal, let's see if it was an enum or
+ // something similar
+ const auto IntConst =
Node.getIdx()->getIntegerConstantExpr(Finder->getAS
@@ -39,6 +39,23 @@ void constant_idx_unsafe(unsigned idx) {
buffer[10] = 0; // expected-note{{used in buffer access here}}
}
+enum FooEnum {
+ A = 0,
+ B = 1,
+ C = 2,
+ D
+};
+
+void constant_enum_safe() {
+ int buffer[FooEnum::D] = { 0, 1, 2 };
+ buffer[C] = 0;
https://github.com/rnk created https://github.com/llvm/llvm-project/pull/122197
Don't use isPotentiallyOverlapping to control behavior that allows overwriting
previous field data, because the `[[no_unique_address]]` attribute is not
available in any debug info, DWARF or PDB. Instead, just trust
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/122029
>From 1824674744d6fba1dd74c74d54aae9b603d8b854 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Wed, 8 Jan 2025 00:24:09 +
Subject: [PATCH 1/2] Use range-based for to iterate over fields in record
layout, NFC
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/122029
>From 1824674744d6fba1dd74c74d54aae9b603d8b854 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Wed, 8 Jan 2025 00:24:09 +
Subject: [PATCH 1/3] Use range-based for to iterate over fields in record
layout, NFC
https://github.com/rnk commented:
Thanks!
I see we don't actually implement these intrinsics at this point, but fixing
them to avoid redeclaration errors is reasonable.
https://github.com/llvm/llvm-project/pull/122238
___
cfe-commits mailing list
cfe
@@ -33,25 +33,26 @@ using namespace llvm::opt;
namespace {
struct OptNameLess {
- const char *StrTable;
- ArrayRef PrefixesTable;
+ const StringTable *StrTable;
rnk wrote:
Can this be a const reference instead? Is there a reason you chose to make this
a p
@@ -117,13 +121,13 @@ class OptTable {
private:
// A unified string table for these options. Individual strings are stored as
// null terminated C-strings at offsets within this table.
- const char *StrTable;
+ const StringTable *StrTable;
rnk wrote:
Can
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/123308
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk commented:
Thanks, I just had one question.
https://github.com/llvm/llvm-project/pull/123308
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -249,6 +249,11 @@ FIELD(HasDeclaredCopyAssignmentWithConstParam, 1, MERGE_OR)
/// base classes or fields have a no-return destructor
FIELD(IsAnyDestructorNoReturn, 1, NO_MERGE)
+/// Microsoft CXX ABI specific:
+/// Whether the copy constructor is used by a `throw` expressio
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/114075
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,19 @@
+// REQUIRES: system-windows, target={{.*-windows-msvc}}
+// RUN: %clang_cc1 -x c++ -std=c++17 -fcxx-exceptions -fexceptions
-triple=%ms_abi_triple -emit-pch -building-pch-with-obj -fmodules-codegen -o
%t.pch %S/cxx-exception-copy-ctor-crash.h
+// RUN: %clang_cc
@@ -2316,6 +2316,20 @@ void
ASTDeclReader::VisitCXXConstructorDecl(CXXConstructorDecl *D) {
}
VisitCXXMethodDecl(D);
+
+ // Microsoft CXX ABI specific:
+ // Restore the RecordToCopyCtor sidecar LUT entry so that `throw` expressions
+ // find the correct copy constructo
https://github.com/rnk commented:
I think @majnemer added the lookup table originally. I think we did things this
way because, while it creates obvious serialization problems, it's the most
straightforwardly correct approach if you think finding copy constructors is an
ambiguous operation. It'
@@ -117,13 +121,13 @@ class OptTable {
private:
// A unified string table for these options. Individual strings are stored as
// null terminated C-strings at offsets within this table.
- const char *StrTable;
+ const StringTable *StrTable;
rnk wrote:
Got
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/123308
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1301 - 1400 of 1563 matches
Mail list logo
