[PATCH] D159126: [Clang] Add captures to the instantiation scope of lambda call operators

BertalanD added a comment. FYI, we found a crash related to this patch: https://github.com/llvm/llvm-project/issues/67260 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D159126/new/ https://reviews.llvm.org/D159126 _

[PATCH] D156156: [clang] Implement constexpr evaluation for `__builtin_{add,sub}c`

BertalanD abandoned this revision. BertalanD added a comment. Moved to https://github.com/llvm/llvm-project/pull/66005 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156156/new/ https://reviews.llvm.org/D156156 _

[PATCH] D156156: [clang] Implement constexpr evaluation for `__builtin_{add,sub}c`

BertalanD created this revision. BertalanD added reviewers: aaron.ballman, cjdb, erichkeane. Herald added a project: All. BertalanD requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. GCC has gained support for these multiprecision arithmetic b

[PATCH] D154397: [Driver] Default to -ftls-model=initial-exec on SerenityOS

BertalanD added a comment. Hi MaskRay! Your blog post (alongside the Drepper TLS doc) proved to be a very helpful resource for our implementation of the dynamic TLS interface. I currently have a SerenityOS PR open that implements `__tls_get_a

[PATCH] D151952: [clang] adds `__type_pack_index` so we can get a type's parameter pack index

BertalanD added a subscriber: jwakely. BertalanD added a comment. I am considering making use of this feature in a real-world project. I have a few short observations after rebasing this diff and playing with it for a bit: - It seems to me that `__has_builtin(__type_pack_index)` currently evalu

[PATCH] D134529: [C++20][Clang] P2468R2 The Equality Operator You Are Looking For

BertalanD added a comment. Thank you all for the help and clarification! I'll go fix our code then. As an aside, I understand that this paper now retroactively applies to the C++ standard, but code has already been written that assumes that what my example is doing is valid. Does it deserve a m

[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

BertalanD added a comment. (I know this is a very contrived example with `void operator!=`, but that is what CVise spat out, and the actual failures are related to comparison operators too) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126907/new/

[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

BertalanD added a comment. I tried out D135772 , and our build got significantly farther than before! I unfortunately discovered another piece of code that pre babdef27c503c0bbbcc017e9f88affddda90ea4e

[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

BertalanD added a comment. In D126907#3849583 , @erichkeane wrote: > In D126907#3846591 , @erichkeane > wrote: > >> In D126907#3844788 , @BertalanD >> wrote: >> >>> Hi

[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

BertalanD added a comment. Hi @erichkeane, This change broke compilation of this program (https://godbolt.org/z/KrWGvcf8h; reduced from https://github.com/SerenityOS/ladybird): template constexpr bool IsSame = false; template constexpr bool IsSame = true; template struct Foo {

[PATCH] D130689: [LLVM] Update C++ standard to 17

BertalanD added inline comments. Comment at: llvm/cmake/modules/CheckCompilerVersion.cmake:79-80 set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -std=c++0x") # Test for libstdc++ version of at least 4.8 by checking for _ZNKSt17bad_function_call4whatEv. # Note: W

[PATCH] D124736: [CodeGen] Use ABI alignment for placement new

BertalanD added a comment. Could you please commit this for me, @rjmccall? I'm wondering if there's a chance this could be backported to the LLVM 14 branch. We've been running into the linked issue in production, it would be great if it were fixed in the next point release. Repository: rG

[PATCH] D124736: [CodeGen] Use ABI alignment for placement new

BertalanD updated this revision to Diff 428225. BertalanD added a comment. Use ABI alignment for allocating operator new as well. Sorry for the delay. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124736/new/ https://reviews.llvm.org/D124736 File

[PATCH] D124736: [CodeGen] Use ABI alignment for placement new

BertalanD added a comment. In D124736#3485128 , @rjmccall wrote: > It should probably be the ABI alignment in all cases; I think the preferred > alignment is just supposed to be used to opportunistically over-align things > like e.g. local variables, wh

[PATCH] D124736: [CodeGen] Use ABI alignment for placement new

BertalanD updated this revision to Diff 426303. BertalanD added a comment. Removed accidental execute permission from the test. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124736/new/ https://reviews.llvm.org/D124736 Files: clang/lib/CodeGen/C

[PATCH] D124736: [CodeGen] Use ABI alignment for placement new

BertalanD updated this revision to Diff 426301. BertalanD added a comment. Added a test case. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124736/new/ https://reviews.llvm.org/D124736 Files: clang/lib/CodeGen/CGExprCXX.cpp clang/test/CodeGenC

[PATCH] D124736: [CodeGen] Use ABI alignment for placement new

BertalanD created this revision. Herald added a project: All. BertalanD requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. If we do not know the alignment of the operand, we can't assume it has the preferred alignment. It might be e.g. a point