rnk wrote:
I added some reviewers to increase visibility. This warning is designed to
avoid common pitfalls with shared objects and hidden visibility as I understand
it, so I thought @maskray might be able to help with some ELF linker/loader
insight as to whether this warning is valuable.
htt
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
https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/122029
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
Thanks for the review!
> nitpick, I don't think this is an NFC change. It would require some thought
> to really convince myself this did not have subtle behavior changes even if
> unintended.
I agree this change assumes some invariants about immutability of field
ordering to be c
@@ -3115,7 +3115,19 @@ class FieldDecl : public DeclaratorDecl, public
Mergeable {
/// Returns the index of this field within its record,
/// as appropriate for passing to ASTRecordLayout::getFieldOffset.
- unsigned getFieldIndex() const;
+ unsigned getFieldIndex() cons
@@ -3115,7 +3115,19 @@ class FieldDecl : public DeclaratorDecl, public
Mergeable {
/// Returns the index of this field within its record,
/// as appropriate for passing to ASTRecordLayout::getFieldOffset.
- unsigned getFieldIndex() const;
+ unsigned getFieldIndex() cons
@@ -3115,7 +3115,19 @@ class FieldDecl : public DeclaratorDecl, public
Mergeable {
/// Returns the index of this field within its record,
/// as appropriate for passing to ASTRecordLayout::getFieldOffset.
- unsigned getFieldIndex() const;
+ unsigned getFieldIndex() cons
@@ -3115,7 +3115,19 @@ class FieldDecl : public DeclaratorDecl, public
Mergeable {
/// Returns the index of this field within its record,
/// as appropriate for passing to ASTRecordLayout::getFieldOffset.
- unsigned getFieldIndex() const;
+ unsigned getFieldIndex() cons
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/3] 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/2] Use range-based for to iterate over fields in record
layout, NFC
https://github.com/rnk created https://github.com/llvm/llvm-project/pull/122029
Move the common case of FieldDecl::getFieldIndex() inline to mitigate the cost
of removing the extra `FieldNo` induction variable.
Also rename isNoUniqueAddress parameter to isNonVirtualBaseType, which appears
to b
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
@@ -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
@@ -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;
+
@@ -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:
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;
+
@@ -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
@@ -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
@@ -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
@@ -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
-
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
@@ -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
@@ -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
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
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
@@ -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
@@ -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->
@@ -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;
@@ -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
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
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
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:
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
___
@@ -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
@@ -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
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
@@ -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 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
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
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:
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
@@ -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
@@ -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
https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/91014
___
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/91014
>From 88e4991013a05e26cece87d3989ad957a4e18e3d Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Wed, 4 Sep 2024 16:52:49 +
Subject: [PATCH 1/6] [clang] Fix FIXME in dynamic initializer emission, NFCI
This poten
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/91014
>From 88e4991013a05e26cece87d3989ad957a4e18e3d Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Wed, 4 Sep 2024 16:52:49 +
Subject: [PATCH 1/5] [clang] Fix FIXME in dynamic initializer emission, NFCI
This poten
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/91990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -13,3 +15,18 @@ template
struct S3 {
int T::*foo;
};
+
+template struct Base {};
+struct
+S5 // #S5
+:
+Base
+// expected-error@-1 {{member pointer has incomplete base type 'S5'}}
rnk wrote:
I agree on the desired behavior, but doesn't this test show tha
https://github.com/rnk commented:
Sorry, looks like I wrote pending comments and didn't publish them
https://github.com/llvm/llvm-project/pull/91990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
@@ -215,6 +215,14 @@ struct NewUnspecified;
SingleTemplate tmpl_single;
UnspecTemplate tmpl_unspec;
+// Member pointers used in base specifiers force an unspecified inheritance
model
+struct MemPtrInBase : UnspecTemplate {};
rnk wrote:
Yes, but it's not clea
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/91014
>From 88e4991013a05e26cece87d3989ad957a4e18e3d Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Wed, 4 Sep 2024 16:52:49 +
Subject: [PATCH 1/4] [clang] Fix FIXME in dynamic initializer emission, NFCI
This poten
Author: Reid Kleckner
Date: 2024-09-04T17:34:26Z
New Revision: 601645c3b70e2a17d18779a3a51b8bc9ecdc9aa6
URL:
https://github.com/llvm/llvm-project/commit/601645c3b70e2a17d18779a3a51b8bc9ecdc9aa6
DIFF:
https://github.com/llvm/llvm-project/commit/601645c3b70e2a17d18779a3a51b8bc9ecdc9aa6.diff
LOG:
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/91014
>From 88e4991013a05e26cece87d3989ad957a4e18e3d Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Wed, 4 Sep 2024 16:52:49 +
Subject: [PATCH 1/4] [clang] Fix FIXME in dynamic initializer emission, NFCI
This poten
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/107154
>From cfb2cea5a4d4e0c1712e038692c4c5acee6b1f27 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Tue, 3 Sep 2024 21:16:40 +
Subject: [PATCH 1/3] [MS] Put dllexported inline global initializers in a
comdat
Foll
rnk wrote:
Yeah, I should've explicitly said I was working on updating the comment block.
It needed significant surgery. Actually, this code could probably use more
significant refactoring, but let's set that aside for now.
> Does this impact non-MS targets?
At the moment, I can't think of a
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/107154
>From cfb2cea5a4d4e0c1712e038692c4c5acee6b1f27 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Tue, 3 Sep 2024 21:16:40 +
Subject: [PATCH 1/2] [MS] Put dllexported inline global initializers in a
comdat
Foll
rnk wrote:
I think there is no change here in our conformance on inline variable
initialization order, except that non-discardable inline variables (achieved in
this instance with dllexport, but perhaps there are other ways to do this. The
classic case is explicit instantiation, which is unord
https://github.com/rnk created https://github.com/llvm/llvm-project/pull/107154
Follow-up to c19f4f8069722f6804086d4438a0254104242c46 to handle corner case of
exported inline variables.
Should fix #56485
>From cfb2cea5a4d4e0c1712e038692c4c5acee6b1f27 Mon Sep 17 00:00:00 2001
From: Reid Kleckne
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
rnk wrote:
Something to consider is that `-fms-extensions` has, at various points, been
used as a tool for making Windows code portable to Apple platforms. So, there
may be users out there who use references in unions on non-Windows platforms.
However, they presumably also build with modern ve
@@ -950,6 +950,9 @@ void CodeGenModule::Release() {
UsedArray.push_back(llvm::ConstantExpr::getPointerBitCastOrAddrSpaceCast(
GetAddrOfGlobal(GD), Int8PtrTy));
}
+// Sort decls by name to always emit them in deterministic order.
rnk wrot
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
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
https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/97792
___
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, looks good, I'll wait for premerge checks to come back green before I
merge it.
https://github.com/llvm/llvm-project/pull/97792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
rnk wrote:
I'm not seeing how your example constitutes an ODR violation, or how merging
these lambda types by mangled name is incorrect. They are equivalent in your
example. It seems like the issue has more to do with the details of how exactly
we do the merge, and where the metadata reference
@@ -5138,7 +5148,11 @@ TryReferenceInit(Sema &S, Expr *Init, QualType DeclType,
// -- Otherwise, the reference shall be an lvalue reference to a
//non-volatile const type (i.e., cv1 shall be const), or the
reference
//shall be an rvalue reference.
-
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/99833
___
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.
I think this looks good, but I would appreciate another reviewer looking at the
patch.
https://github.com/llvm/llvm-project/pull/99833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
@@ -1938,12 +1946,23 @@ void
MicrosoftCXXNameMangler::mangleTemplateArgValue(QualType T,
mangleNumber(V.getLValueOffset().getQuantity());
} else if (!V.hasLValuePath()) {
// FIXME: This can only happen as an extension. Invent a mangling.
-break;
+
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/97792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk commented:
Sorry, I made this comment some time ago, but it looks like I never published it
https://github.com/llvm/llvm-project/pull/97792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/99426
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -154,3 +154,133 @@ a hint suggesting how to fix the problem.
As of this writing, Clang is able to compile a simple ATL hello world
application. There are still issues parsing WRL headers for modern Windows 8
apps, but they should be addressed soon.
+
+__forceinline behavior
@@ -154,3 +154,133 @@ a hint suggesting how to fix the problem.
As of this writing, Clang is able to compile a simple ATL hello world
application. There are still issues parsing WRL headers for modern Windows 8
rnk wrote:
"modern Windows 8" is obviously stale
@@ -9015,11 +9015,20 @@ bool Sema::RequireCompleteTypeImpl(SourceLocation Loc,
QualType T,
if (const MemberPointerType *MPTy = T->getAs()) {
if (!MPTy->getClass()->isDependentType()) {
- if (getLangOpts().CompleteMemberPointers &&
- !MPTy->getClass()->getA
@@ -215,6 +215,14 @@ struct NewUnspecified;
SingleTemplate tmpl_single;
UnspecTemplate tmpl_unspec;
+// Member pointers used in base specifiers force an unspecified inheritance
model
+struct MemPtrInBase : UnspecTemplate {};
rnk wrote:
I guess this memptr ty
@@ -13,3 +15,18 @@ template
struct S3 {
int T::*foo;
};
+
+template struct Base {};
+struct
+S5 // #S5
+:
+Base
+// expected-error@-1 {{member pointer has incomplete base type 'S5'}}
rnk wrote:
Should this be an error in Microsoft mode? Shouldn't we silentl
rnk wrote:
I lost the `__fastcall` or `__vectorcall` during editing, here's a fixed link:
https://godbolt.org/z/46j33z8bc
You can see the load from [edx] and store to [ecx]:
```
NonTrivial copy_nontrivial(NonTrivial *) PROC ; copy_nontrivial, COMDAT
mov eax, DWORD PTR [edx]
@@ -185,6 +203,18 @@ CALL_AO(PackedMembers)
// CHECK: call void @llvm.memcpy.p0.p0.i64({{.*}} align 1 {{.*}} align 1
{{.*}}i64 16, i1 {{.*}})
// CHECK: ret ptr
+// WithEmptyField copy-assignment:
+// CHECK-LABEL: define linkonce_odr nonnull align {{[0-9]+}}
dereferenceable({
rnk wrote:
I think this NTTP mangling code needs some significant updates, refactoring,
and an increase in test coverage. I see
cd93532dfc455255cb2fa553090d14aaa52b106b landed last May, probably when I was
offline for a while.
https://github.com/llvm/llvm-project/pull/97792
__
rnk wrote:
Thanks! I was going to say, surely this can't be right, I was pretty confident
that sret pointers consume registers for these conventions, but it looks like I
was mistaken. I think this bug and code dates to
661f35b0c54c79805e6b17944b155c111bc39ec3 from 2014, which I think made the
https://github.com/rnk approved this pull request.
I think this looks good, then. Any other concerns?
https://github.com/llvm/llvm-project/pull/96422
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
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
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
@@ -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
@@ -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';
---
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
1 - 100 of 1365 matches
Mail list logo
