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
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
@@ -298,15 +298,15 @@
// FioRACE2: "-E"
// FioRACE2: "-o" "foo.x"
-// RUN: %clang_cl /Z7 /Foa.obj -### -- %s 2>&1 | FileCheck
-check-prefix=ABSOLUTE_OBJPATH %s
+// RUN: %clang_cl -target x86_64-windows /Z7 /Foa.obj -### -- %s 2>&1 |
FileCheck -check-prefix=ABSOLUTE_OBJPATH %
@@ -5,15 +5,15 @@
// NO_GHASH-NOT: "-gcodeview-ghash"
// default
-// RUN: %clang_cl /Z7 -### -- %s 2>&1 | FileCheck -check-prefix=NO_GHASH %s
+// RUN: %clang_cl -target x86_64-windows /Z7 -### -- %s 2>&1 | FileCheck
-check-prefix=NO_GHASH %s
// enabled
-// RUN: %clang_cl /Z7
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/88245
___
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.
Sorry for the delay, looks good!
https://github.com/llvm/llvm-project/pull/88245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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:
Hey, I went ahead and reverted this patch in
aa0776de464984e78ae1cc329bf541e9dd43631f because it is incompatible with ASan
ThinLTO builds. I think you have uncovered a latent issue in the ASan + thinlto
configuration that is not really the fault of this change, but I didn't see a
Author: Reid Kleckner
Date: 2024-05-10T21:28:13Z
New Revision: aa0776de464984e78ae1cc329bf541e9dd43631f
URL:
https://github.com/llvm/llvm-project/commit/aa0776de464984e78ae1cc329bf541e9dd43631f
DIFF:
https://github.com/llvm/llvm-project/commit/aa0776de464984e78ae1cc329bf541e9dd43631f.diff
LOG:
rnk wrote:
I played with the idea of using LLVM packed structs (`<{ i129 }>`) to represent
something like this, but they don't work the way I expected them to do:
https://godbolt.org/z/M6hMYYhax
LLVM DataLayout's idea of `sizeof(i129)` is still rounded up from 17 bytes to
32 bytes.
Using byt
rnk wrote:
Thanks for the reminder, I missed the update.
https://github.com/llvm/llvm-project/pull/82815
___
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/82815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -424,6 +424,34 @@ void
CGNVCUDARuntime::emitDeviceStubBodyNew(CodeGenFunction &CGF,
CGM.CreateRuntimeFunction(FTy, LaunchKernelName);
CGF.EmitCall(FI, CGCallee::forDirect(cudaLaunchKernelFn), ReturnValueSlot(),
LaunchKernelArgs);
+
+ // To prevent CU
@@ -424,6 +424,34 @@ void
CGNVCUDARuntime::emitDeviceStubBodyNew(CodeGenFunction &CGF,
CGM.CreateRuntimeFunction(FTy, LaunchKernelName);
CGF.EmitCall(FI, CGCallee::forDirect(cudaLaunchKernelFn), ReturnValueSlot(),
LaunchKernelArgs);
+
+ // To prevent CU
@@ -424,6 +424,34 @@ void
CGNVCUDARuntime::emitDeviceStubBodyNew(CodeGenFunction &CGF,
CGM.CreateRuntimeFunction(FTy, LaunchKernelName);
CGF.EmitCall(FI, CGCallee::forDirect(cudaLaunchKernelFn), ReturnValueSlot(),
LaunchKernelArgs);
+
+ // To prevent CU
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule &CGM) {
+ // If the record is marked with the trivial_abi attribute, we don'
Author: Reid Kleckner
Date: 2024-04-29T22:09:09Z
New Revision: 1f44a0b1ff2daebe10b9916da228f7c0ba66827c
URL:
https://github.com/llvm/llvm-project/commit/1f44a0b1ff2daebe10b9916da228f7c0ba66827c
DIFF:
https://github.com/llvm/llvm-project/commit/1f44a0b1ff2daebe10b9916da228f7c0ba66827c.diff
LOG:
rnk wrote:
Sorry for the delay, work life does its best to intervene.
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule &CGM) {
+ // If the record is marked with the trivial_abi attribute, we don'
https://github.com/rnk approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/90151
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule &CGM) {
+ // If the record is marked with the trivial_abi attribute, we don'
https://github.com/rnk requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/88857
___
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/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule &CGM) {
+ // If the record is marked with the trivial_abi attribute, we don'
rnk wrote:
So, I was completely unaware that trivial relocatability had been picked up at
all by WG21. Since the beginning of `trivial_abi`, I we were solidly in the
vendor-extension space trying to build non-standard but practical solutions to
real world problems, like the fact that we couldn
https://github.com/rnk approved this pull request.
Thank you for polishing this corner of the driver interface! It's interesting
that they have an alternative separate spelling. I always felt like the
`/Fopath.cpp` pattern was a bit unreadable.
https://github.com/llvm/llvm-project/pull/88216
_
https://github.com/rnk approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -std=c++11 -fcxx-exceptions
-fexceptions -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: %[[STRUCT_TRIVIAL:.*]] = type { ptr }
+struct __attribute__((trivial_abi)) Trivial {
+ int *p;
+ Trivial() : p(0) {}
+ Tr
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -std=c++11 -fcxx-exceptions
-fexceptions -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: %[[STRUCT_TRIVIAL:.*]] = type { ptr }
+struct __attribute__((trivial_abi)) Trivial {
+ int *p;
+ Trivial() : p(0) {}
+ Tr
@@ -63,6 +63,10 @@ ABI Changes in This Version
MSVC uses a different mangling for these objects, compatibility is not
affected.
(#GH85423).
+- The attribute ``trivial_abi`` now works when targetting the Microsoft ABI.
Marking
rnk wrote:
It's overly broa
https://github.com/rnk approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/88751
___
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.
https://github.com/llvm/llvm-project/pull/88101
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
To restate the finding, 29% of .debug_info is describing class methods, at
least in Clang.
I think this is a useful mode, and we should land it as is. There are many
users up against the scaling limits of debug info size, and it's helpful to
have this as an option for experimentati
https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/87209
___
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.
https://github.com/llvm/llvm-project/pull/87209
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
That's interesting! I wonder how long the /F flags have accepted trailing
colons. That form seems a lot more readable.
I went looking for examples of how to do this with fewer aliases, but it looks
like this is what is done currently:
https://github.com/llvm/llvm-project/blob/main/c
rnk wrote:
> As a data point, I've been setting core.autocrlf=true on Windows for years.
If that's the case, my information is stale, which I accept.
> To be clear, this may do nothing on checkout if a user has set a config
> option.
That addresses my concerns.
https://github.com/llvm/llv
rnk wrote:
I think it makes sense to remove carriage returns on checkin, but I'm not sure
it makes sense to add them back on checkout on Windows. Historically, it's been
really easy to write LLVM tests that fail when the source is checked out with
CRLF. Many Windows developers have noted that
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/86039
___
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/81677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,81 @@
+//===-- sanitizer_win_thunk_interception.h -
-===//
+//
+// 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 commented:
Is it feasible to create a migration path from the static runtime to the
dynamic runtime? As written, this requires users to update their ASan builds at
the same time that they take this update. Is it possible to leave the static
runtime behind, create a migra
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/81677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 1323 matches
Mail list logo