https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH 1/7] Add an off-by-default warning to complain about MSVC
bitfield
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH 1/6] [Clang] Consider preferred_type in bitfield warnings
(#116760)
ojhunt wrote:
> > This does mean that if the preferred and explicit types have different
> > storage requirements we may not warn in all possible cases, but that's a
> > scenario for which the warnings are much more complex and confusing
>
> If I understand the patch correctly, we always warn,
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH 1/6] [Clang] Consider preferred_type in bitfield warnings
(#116760)
ojhunt wrote:
> > This does mean that if the preferred and explicit types have different
> > storage requirements we may not warn in all possible cases, but that's a
> > scenario for which the warnings are much more complex and confusing
>
> If I understand the patch correctly, we always warn,
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH 1/6] [Clang] Consider preferred_type in bitfield warnings
(#116760)
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH 1/7] Add an off-by-default warning to complain about MSVC
bitfield
ojhunt wrote:
> (while too lazy to godbolt right now)
Given I basically wrote the entire example, I thought I would just do the
godbolting, and lo
```cpp
enum class Enum {
A, B, C, D
};
struct S {
Enum e: 1; // I'm a rockstar developer and "know" that I'll only ever assign
A or B here
};
ojhunt wrote:
> > and I thought making just preferred_type warnings early would be especially
> > insane :D
>
> I don't necessarily agree. `preferred_type` is a relatively new thing, so we
> can try doing something new here.
>
Yeah, but the implementation is essentially identical, so I would
ojhunt wrote:
> Looking at diagnostics in the test you add, I wonder why don't we issue them,
> and especially the fixit, when we parse bit-field declaration. Why waiting
> until assignment happens?
Yeah, it's super frustrating to me that we do that - I did _consider_ making
them early but I
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH 1/6] [Clang] Consider preferred_type in bitfield warnings
(#116760)
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH 1/5] [Clang] Consider preferred_type in bitfield warnings
(#116760)
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH 1/7] Add an off-by-default warning to complain about MSVC
bitfield
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH 1/5] [Clang] Consider preferred_type in bitfield warnings
(#116760)
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH 1/4] [Clang] Consider preferred_type in bitfield warnings
(#116760)
ojhunt wrote:
> > > So I take it we decided not to enable it by default in
> > > `-fms-compatibility` mode then?
> >
> >
> > I don't believe it is appropriate to do so. The intent of this warning is
> > to indicate MSVC compatibility issues when building in non-ms-compatibility
> > modes. Th
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH 1/6] Add an off-by-default warning to complain about MSVC
bitfield
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/118428
>From aea2b4001aa8e9239909875153152083b56a6a59 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Mon, 2 Dec 2024 21:25:54 -0800
Subject: [PATCH 1/3] Add support for referencable labels for attribute
documentation
ojhunt wrote:
> LGTM after fixing one more thing.
>
> I personally think this is a reasonable addition now, but please wait for
> Aaron or Erich to approve this too before merging.
Righto, I've committed the change, is `const StringRef` a style violation (I
recognize StringRef is a constant t
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/118428
>From aea2b4001aa8e9239909875153152083b56a6a59 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Mon, 2 Dec 2024 21:25:54 -0800
Subject: [PATCH 1/3] Add support for referencable labels for attribute
documentation
ojhunt wrote:
> Also, if/when this is merged, it would be nice if someone could go through
> the rest of the docs and apply this wherever possible (assuming there are any
> other places where we still need to do that).
yeah, I wanted to isolate this for now to just the attribute docs as these
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/118428
>From aea2b4001aa8e9239909875153152083b56a6a59 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Mon, 2 Dec 2024 21:25:54 -0800
Subject: [PATCH 1/2] Add support for referencable labels for attribute
documentation
ojhunt wrote:
> I have no idea what is going on here... @AaronBallman probably needs to take
> a better look. Else, could the author please give me an ELI5 sorta thing here
> or show me what the change looks like on the generated stuff?
Sure! This example will cover the docs used in the [above
ojhunt wrote:
> Out of curiosity, why does the existing mechanism not suffice?
it "works" but creates the tag at the beginning of the text rather than the
beginning of the attribute documentation. The result is that the scroll target
for linking is the beginning of the text rather than the doc
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/118428
>From aea2b4001aa8e9239909875153152083b56a6a59 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Mon, 2 Dec 2024 21:25:54 -0800
Subject: [PATCH] Add support for referencable labels for attribute
documentation
Th
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/118428
>From aea2b4001aa8e9239909875153152083b56a6a59 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Mon, 2 Dec 2024 21:25:54 -0800
Subject: [PATCH] Add support for referencable labels for attribute
documentation
Th
https://github.com/ojhunt created
https://github.com/llvm/llvm-project/pull/118428
The existing mechanism being used is to manually add a reference in the
documentation. These references link to the beginning of the text rather than
the heading for the attribute which is what this PR allows.
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH 1/6] Add an off-by-default warning to complain about MSVC
bitfield
ojhunt wrote:
> So I take it we decided not to enable it by default in `-fms-compatibility`
> mode then?
I don't believe it is appropriate to do so. The intent of this warning is to
indicate MSVC compatibility issues when building in non-ms-compatibility modes.
The existing padding warnings a
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH 1/5] Add an off-by-default warning to complain about MSVC
bitfield
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH 1/4] [Clang] Consider preferred_type in bitfield warnings
(#116760)
ojhunt wrote:
Independently of the rationale for the current behaviour, I would be extremely
concerned about potential breakage from this behavior change (more due to
hyrum's law that intentional choices)
https://github.com/llvm/llvm-project/pull/115993
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH 1/4] Add an off-by-default warning to complain about MSVC
bitfield
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH 1/3] [Clang] Consider preferred_type in bitfield warnings
(#116760)
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH 1/4] Add an off-by-default warning to complain about MSVC
bitfield
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH 1/3] Add an off-by-default warning to complain about MSVC
bitfield
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH 1/2] Add an off-by-default warning to complain about MSVC
bitfield
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/117428
>From 3e25d7ef2e223942298078dace8979905956d05c Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 22 Nov 2024 17:53:24 +0100
Subject: [PATCH] Add an off-by-default warning to complain about MSVC bitfield
padd
https://github.com/ojhunt ready_for_review
https://github.com/llvm/llvm-project/pull/113510
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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
@@ -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->
@@ -10509,14 +10516,18 @@ static bool AnalyzeBitFieldAssignment(Sema &S,
FieldDecl *Bitfield, Expr *Init,
ED->getNumPositiveBits() == FieldWidth) {
DiagID = diag::warn_signed_bitfield_enum_conversion;
}
-
+ unsigned PreferredTypeDiagIndex =
ojhunt wrote:
@erichkeane @Fznamznon what should the release note be - just something akin to
"added warning flag -W... to warn when bitfield packing differs from MSVC"?
https://github.com/llvm/llvm-project/pull/116785
___
cfe-commits mailing list
cfe
ojhunt wrote:
Oh, my goal for this warning is to have us turn it on in the llvm+clang builds,
so we can then move away from endless use of unsigned bitfields and just use
enums as nature intended :D (cc @AaronBallman )
https://github.com/llvm/llvm-project/pull/117428
__
ojhunt wrote:
This has been tentatively approved C++26 - CWG didn't have time to look at it
this week but EWG and SG23 have approved it. I did spend some time discussing
semantics with a couple of folk in EWG and CWG and the feedback was fairly
strongly on the side of "the operator delete used
https://github.com/ojhunt created
https://github.com/llvm/llvm-project/pull/117428
This just adds a warning for bitfields placed next to other bitfields where the
underlying type has different storage. Under the MS struct bitfield packing ABI
such bitfields are not packed.
>From 3e25d7ef2e223
ojhunt wrote:
> > Could anyone with a windows machine see if you can work out what is
> > happening with the windows test failure? I don't understand why the tests
> > are failing on the windows bot as it seems like it should simply fail
> > everything (e.g. windows driver is going wrong) or i
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH 1/3] [Clang] Consider preferred_type in bitfield warnings
(#116760)
ojhunt wrote:
There's a side note that I didn't want to change in this PR: gcc warns on the
declaration of the fields, not just the use, but that would be a completely new
warning so I didn't want to conflate the issues.
https://github.com/llvm/llvm-project/pull/116785
@@ -0,0 +1,108 @@
+// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin10 -fsyntax-only -verify
-std=c11 -Wno-unused-value -Wno-unused-but-set-variable -Wbitfield-width
-Wbitfield-enum-conversion
+
+enum A {
+ A_a,
+ A_b,
+ A_c,
+ A_d
+};
+
+struct S {
+ enum A a1 : 1; // #1
-
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/116785
>From 5f260726253e78a00d2dff02c22837ce02b49075 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Tue, 19 Nov 2024 11:55:11 +0100
Subject: [PATCH] [Clang] Consider preferred_type in bitfield warnings
(#116760)
Ve
https://github.com/ojhunt created
https://github.com/llvm/llvm-project/pull/116785
Very simply extends the bitfield sema checks for assignment to fields with a
preferred type specified to consider the preferred type if the decl storage
type is not explicitly an enum type.
This does mean that
https://github.com/ojhunt closed
https://github.com/llvm/llvm-project/pull/116784
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ojhunt created
https://github.com/llvm/llvm-project/pull/116784
Very simply extends the bitfield sema checks for assignment to fields with a
preferred type specified to consider the preferred type if the decl storage
type is not explicitly an enum type.
This does mean that
ojhunt wrote:
Could anyone with a windows machine see if you can work out what is happening
with the windows test failure? I don't understand why the tests are failing on
the windows bot as it seems like it should simply fail everything (e.g. windows
driver is going wrong) or it should work
h
https://github.com/ojhunt edited
https://github.com/llvm/llvm-project/pull/113510
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ojhunt wrote:
Ok, so I've gone through all my GitHub settings, and am hoping for a comment or
something, to see if GH will actually ping me this time :D
https://github.com/llvm/llvm-project/pull/113510
___
cfe-commits mailing list
cfe-commits@lists.ll
ojhunt wrote:
also sorry for cycling to and from "review" the GH interface is still not
obvious to me
https://github.com/llvm/llvm-project/pull/113510
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
@@ -307,6 +307,10 @@ EXTENSION(datasizeof, LangOpts.CPlusPlus)
FEATURE(cxx_abi_relative_vtable, LangOpts.CPlusPlus &&
LangOpts.RelativeCXXABIVTables)
+// Type aware allocators
+FEATURE(cxx_type_aware_allocators, LangOpts.TypeAwareAllocators)
ojhunt wrote:
O
https://github.com/ojhunt converted_to_draft
https://github.com/llvm/llvm-project/pull/113510
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3358,6 +3358,12 @@ bool FunctionDecl::isReservedGlobalPlacementOperator()
const {
return false;
const auto *proto = getType()->castAs();
+ if (proto->getNumParams() < 2)
+return false;
+ bool IsTypeAwareAllocator =
ojhunt wrote:
Yeah, I think
@@ -8126,7 +8143,7 @@ class Sema final : public SemaBase {
/// The scope in which to find allocation functions.
enum AllocationFunctionScope {
-/// Only look for allocation functions in the global scope.
+/// Only look for allocation functions in the global scope
-
@@ -4749,6 +4753,15 @@ class Sema final : public SemaBase {
CXXRecordDecl *getStdBadAlloc() const;
EnumDecl *getStdAlignValT() const;
+ ClassTemplateDecl *getStdTypeIdentity() const;
+ std::optional InstantiateSpecializedTypeIdentity(QualType Subject);
o
@@ -2234,6 +2234,17 @@ enum class CXXNewInitializationStyle {
Braces
};
+struct ImplicitAllocationParameters {
+ bool PassTypeIdentity;
ojhunt wrote:
What is the rationale for bitfields?
I'm generally opposed to flag enums as the language support is so po
ojhunt wrote:
@cor3ntin oh yeah, I know, I'm also there :D
https://github.com/llvm/llvm-project/pull/113510
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ojhunt wrote:
LGTM
https://github.com/llvm/llvm-project/pull/109056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ojhunt wrote:
I’m a little concerned about not allowing the attribute in C++ - the existence
of other options in C++ does not mean they are an option (due to various and
sundry restrictions of C++ version upgrades different projects have), but also
you trivially end up in cases where header co
ojhunt wrote:
Ok, it took me a moment to understand what was happening here - I had to talk
to Ahmed because I didn't recognize the AddrDiscriminator_* enums and had
assumed I'd forgotten them :D
This needs to update `ItaniumRTTIBuilder::BuildVTablePointer` to take the
storage address, and t
@@ -3955,9 +3955,23 @@ void ItaniumRTTIBuilder::BuildVTablePointer(const Type
*Ty) {
VTable, Two);
}
- if (auto &Schema = CGM.getCodeGenOpts().PointerAuth.CXXTypeInfoVTablePointer)
-VTable = CGM.getConstantSigne
ojhunt wrote:
@AaronBallman ah with more context, I see we didn't actually land "// Do
something if not an identifier" (implying partial commit history at some
point". I'm looking at exactly what happens, or if we're missing some test
cases -- it's possible that when written there was the inte
ojhunt wrote:
@AaronBallman hmmm, looks like we may have lost some diff at some point, I'll
investigate to work out what is going on
https://github.com/llvm/llvm-project/pull/3
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
ojhunt wrote:
Looks good to me (spent a bit of time verifying correct auth logic, but for the
actual elf specific codegen I can't comment)
https://github.com/llvm/llvm-project/pull/100206
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/99604
>From 640779f0327c3b3773ff055923c59a82ae6c7f30 Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Thu, 18 Jul 2024 21:08:12 -0700
Subject: [PATCH 1/2] [clang][test] Add function type discrimination tests to
ptrauth
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/99576
>From 547ce3e9c7fe7e046b20f51f2f0d370a683659d1 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Fri, 10 May 2024 15:58:57 -0700
Subject: [PATCH 1/2] [PAC] Implement pointer authentication for C++ member
functi
https://github.com/ojhunt edited https://github.com/llvm/llvm-project/pull/99576
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1036,9 +1155,32 @@ llvm::Constant *ItaniumCXXABI::BuildMemberPointer(const
CXXMethodDecl *MD,
// least significant bit of adj then makes exactly the same
// discrimination as the least significant bit of ptr does for
// Itanium.
- MemPtr[0] = l
@@ -71,6 +71,15 @@ void has_ptrauth_vtable_pointer_type_discrimination() {}
void no_ptrauth_vtable_pointer_type_discrimination() {}
#endif
+// This is always enabled when ptrauth_calls is enabled, on new enough clangs.
ojhunt wrote:
Weird mismerge I guess?
-
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/99741
>From 5822eb8f5b0d420a89d539f8fd2e23c69983967a Mon Sep 17 00:00:00 2001
From: Oliver Hunt
Date: Fri, 19 Jul 2024 22:48:26 -0700
Subject: [PATCH 1/2] [PAC] Incorrect codegen for constant global init with
polymorph
ojhunt wrote:
@ahmedbougacha @asl @kovdan01 pinging for review
https://github.com/llvm/llvm-project/pull/99741
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ojhunt created
https://github.com/llvm/llvm-project/pull/99741
Fixes an error where we use the wrong authentication schema for secondary
vtable pointers in constant initialized globals of types with multiple
polymorphic base classes.
>From 5822eb8f5b0d420a89d539f8fd2e23c699
ojhunt wrote:
@asl could you check this as well? (I apparently can't add/request reviewers?)
https://github.com/llvm/llvm-project/pull/99576
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
https://github.com/ojhunt ready_for_review
https://github.com/llvm/llvm-project/pull/99576
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/99576
>From 547ce3e9c7fe7e046b20f51f2f0d370a683659d1 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Fri, 10 May 2024 15:58:57 -0700
Subject: [PATCH] [PAC] Implement pointer authentication for C++ member
function p
https://github.com/ojhunt ready_for_review
https://github.com/llvm/llvm-project/pull/99604
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ojhunt created
https://github.com/llvm/llvm-project/pull/99604
I accidentally did not include tests for the setting up runtime calls when
compiling with -fptrauth-function-pointer-type-discrimination
>From 640779f0327c3b3773ff055923c59a82ae6c7f30 Mon Sep 17 00:00:00 2001
Fro
https://github.com/ojhunt edited https://github.com/llvm/llvm-project/pull/99576
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/99576
>From 547ce3e9c7fe7e046b20f51f2f0d370a683659d1 Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Fri, 10 May 2024 15:58:57 -0700
Subject: [PATCH] [PAC] Implement pointer authentication for C++ member
function p
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/99576
>From c2bc964341fb4d0738e94d4afa6abc84eed0113c Mon Sep 17 00:00:00 2001
From: Ahmed Bougacha
Date: Fri, 10 May 2024 15:58:57 -0700
Subject: [PATCH] [clang] Implement pointer authentication for C++ member
function
https://github.com/ojhunt created
https://github.com/llvm/llvm-project/pull/99576
Introduces type based signing of member function pointers. To support this
discrimination schema we no longer emit member function pointer to virtual
methods and indices into a vtable but migrate to using thunks.
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/98276
>From 4b92c4af87a1a381dad09b243db4d3ec71d64738 Mon Sep 17 00:00:00 2001
From: John McCall
Date: Wed, 18 Sep 2019 02:21:37 -0400
Subject: [PATCH 1/5] Sign function pointers passed to atexit and __cxa_atexit.
Patch
ojhunt wrote:
I notice the r+, but I haven't fully addressed this feedback - are you
suggesting corrections in a follow up patch, or just conceptually approving
with this PR? :D
https://github.com/llvm/llvm-project/pull/98276
___
cfe-commits mailing
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/98276
>From 4b92c4af87a1a381dad09b243db4d3ec71d64738 Mon Sep 17 00:00:00 2001
From: John McCall
Date: Wed, 18 Sep 2019 02:21:37 -0400
Subject: [PATCH 1/4] Sign function pointers passed to atexit and __cxa_atexit.
Patch
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -fptrauth-calls -fcxx-exceptions
-emit-llvm %s -o - | FileCheck %s
+
+class Foo {
+ public:
+ ~Foo() {
+ }
+};
+
+// CHECK-LABEL: define void @_Z1fv()
+// CHECK: call void @__cxa_throw(ptr %{{.*}}, ptr @_ZTI3Foo, ptr
@@ -333,7 +338,8 @@ void CodeGenFunction::registerGlobalDtorWithLLVM(const
VarDecl &VD,
llvm::FunctionCallee Dtor,
llvm::Constant *Addr) {
// Create a function which calls the d
https://github.com/ojhunt ready_for_review
https://github.com/llvm/llvm-project/pull/98276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ojhunt edited https://github.com/llvm/llvm-project/pull/98276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ojhunt updated
https://github.com/llvm/llvm-project/pull/98276
>From 4b92c4af87a1a381dad09b243db4d3ec71d64738 Mon Sep 17 00:00:00 2001
From: John McCall
Date: Wed, 18 Sep 2019 02:21:37 -0400
Subject: [PATCH 1/3] Sign function pointers passed to atexit and __cxa_atexit.
Patch
https://github.com/ojhunt created
https://github.com/llvm/llvm-project/pull/98276
Updates codegen for global destructors and raising exceptions to ensure that
the function pointers being passed are signed using the correct schema.
Notably this requires that CodeGenFunction::createAtExitStub to
98 matches
Mail list logo
