[PATCH] D46439: Fix incorrect packed aligned structure layout

chill updated this revision to Diff 145687. https://reviews.llvm.org/D46439 Files: lib/Sema/SemaDecl.cpp test/Layout/itanium-pack-and-align.cpp Index: test/Layout/itanium-pack-and-align.cpp === --- /dev/null +++ test/Layout/ita

[PATCH] D46439: Fix incorrect packed aligned structure layout

chill marked an inline comment as done. chill added a comment. Update: updated comment, added a test. Comment at: lib/Sema/SemaDecl.cpp:15651 } } else { ObjCIvarDecl **ClsFields = rsmith wrote: > Do we need to do any attribute processing in this Ob

[PATCH] D46439: Fix incorrect packed aligned structure layout

chill added a comment. Ping? https://reviews.llvm.org/D46439 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46439: [Sema] Fix incorrect packed aligned structure layout

chill added a comment. Thanks a lot! https://reviews.llvm.org/D46439 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46439: [Sema] Fix incorrect packed aligned structure layout

This revision was automatically updated to reflect the committed changes. Closed by commit rC332843: [Sema] Fix incorrect packed aligned structure layout (authored by chill, committed by ). Changed prior to commit: https://reviews.llvm.org/D46439?vs=145687&id=147781#toc Repository: rC Clang

[PATCH] D38628: Remove unneeded typename from test

chill added a comment. FYI, there is a similar issue in `test/std/utilities/variant/variant.helpers/variant_alternative.fail.cpp` added by the same commit git hash: a12318f5ae0aae44eb17f376d3598717b45f7a5f "Added failing tests for index out of range for tuple_element> and variant_alternativ

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill added a comment. Ping? https://reviews.llvm.org/D46013 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill updated this revision to Diff 157662. chill added a comment. Fixed to properly examine the canonical type when getting it's unadjusted alignment. https://reviews.llvm.org/D46013 Files: include/clang/AST/ASTContext.h include/clang/AST/RecordLayout.h lib/AST/ASTContext.cpp lib/AST/

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill marked an inline comment as done. chill added a comment. Thanks for pointing this! https://reviews.llvm.org/D46013 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

This revision was automatically updated to reflect the committed changes. Closed by commit rC338279: [ARM, AArch64]: Use unadjusted alignment when passing composites as arguments (authored by chill, committed by ). Repository: rC Clang https://reviews.llvm.org/D46013 Files: include/clang/AS

[PATCH] D42736: [DebugInfo] Improvements to representation of enumeration types (PR36168)

This revision was automatically updated to reflect the committed changes. Closed by commit rL324490: [DebugInfo] Improvements to representation of enumeration types (PR36168) (authored by chill, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.ll

[PATCH] D42736: [DebugInfo] Improvements to representation of enumeration types (PR36168)

This revision was automatically updated to reflect the committed changes. Closed by commit rC324490: [DebugInfo] Improvements to representation of enumeration types (PR36168) (authored by chill, committed by ). Repository: rL LLVM https://reviews.llvm.org/D42736 Files: lib/CodeGen/CGDebugIn

[PATCH] D33676: Place implictly declared functions at block scope

chill added a subscriber: cfe-commits. chill added a comment. This issue https://bugs.llvm.org//show_bug.cgi?id=2266 does not appear to trigger anymore, with this patch applied. https://reviews.llvm.org/D33676 ___ cfe-commits mailing list cfe-commi

[PATCH] D33676: Place implictly declared functions at block scope

chill added a comment. In https://reviews.llvm.org/D33676#767746, @rogfer01 wrote: > I understand that the scope `S` in this case is a (function) prototype scope > so it would not be the innermost block scope, would it? That said, GCC does > not accept `p_ok` above so probably this behaviour is

[PATCH] D33676: Place implictly declared functions at block scope

chill updated this revision to Diff 101522. chill added a comment. Update 1 notes. The scopes for compound statements are explicitly marked as such, so then `Sema::ImplicitylDefineFunction` can ascend to the nearest enclosing scope. The function scopes (ones with `Scope:FnScope`) do not necessa

[PATCH] D33676: Place implictly declared functions at block scope

chill updated this revision to Diff 102802. chill added a comment. Update 2: added a testcase involving expression statements https://reviews.llvm.org/D33676 Files: include/clang/Sema/Scope.h lib/Parse/ParseStmt.cpp lib/Sema/SemaDecl.cpp test/Sema/implicit-decl-c90.c test/Sema/implici

[PATCH] D33676: Place implictly declared functions at block scope

chill added inline comments. Comment at: test/Sema/implicit-decl.c:12 int32_t compCount = 0; - if (_CFCalendarDecomposeAbsoluteTimeV(compDesc, vector, compCount)) { // expected-note {{previous implicit declaration is here}} \ - expected-error {{implicit declaration

[PATCH] D33676: Place implictly declared functions at block scope

chill added a comment. Ping? https://reviews.llvm.org/D33676 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill updated this revision to Diff 149252. chill added a comment. Update: - similar changes needed for AArch64 - added/updated tests https://reviews.llvm.org/D46013 Files: include/clang/AST/ASTContext.h include/clang/AST/RecordLayout.h lib/AST/ASTContext.cpp lib/AST/RecordLayout.cpp

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill updated this revision to Diff 149536. chill added a comment. Update: - fix only APCS, don't touch other ABIs - misc other https://reviews.llvm.org/D46013 Files: include/clang/AST/ASTContext.h include/clang/AST/RecordLayout.h lib/AST/ASTContext.cpp lib/AST/RecordLayout.cpp lib/A

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill marked 2 inline comments as done. chill added a comment. In https://reviews.llvm.org/D46013#1118014, @efriedma wrote: > I'm not sure Apple will want to mess with their ABI like this... adding some > reviewers. Fair enough, I'd rather not touch it :) https://reviews.llvm.org/D46013 _

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill updated this revision to Diff 150148. chill added a comment. Update: refactor a bit to not impose size overhead on targets, which don't use natural alignment. https://reviews.llvm.org/D46013 Files: include/clang/AST/ASTContext.h include/clang/AST/RecordLayout.h lib/AST/ASTContext.c

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill added a comment. Ping? https://reviews.llvm.org/D46013 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill added a comment. Ping? https://reviews.llvm.org/D46013 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill added a comment. In https://reviews.llvm.org/D46013#1140336, @t.p.northover wrote: > I'm fine with the ABI changes, but I'm not very convinced by the > "NaturalAlignment" name. I'd rather not put target names in API functions. The meaning of that field is pretty target independent ("ali

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill added inline comments. Comment at: lib/CodeGen/TargetInfo.cpp:5055 + Alignment = getContext().getTypeNaturalAlign(Ty); + Alignment = std::min(std::max(Alignment, 64u), 128u); +} else { t.p.northover wrote: > I think the max/min logic is more c

[PATCH] D64415: Consistent types and naming for AArch64 target features (NFC)

chill accepted this revision. chill added a comment. This revision is now accepted and ready to land. Going to commit as obvious. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64415/new/ https://reviews.llvm.org/D64415 ___ cfe-commits maili

[PATCH] D64415: Consistent types and naming for AArch64 target features (NFC)

This revision was automatically updated to reflect the committed changes. Closed by commit rL366315: [AArch64] Consistent types and naming for AArch64 target features (NFC) (authored by chill, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to

[PATCH] D64415: Consistent types and naming for AArch64 target features (NFC)

chill updated this revision to Diff 210286. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64415/new/ https://reviews.llvm.org/D64415 Files: clang/lib/Basic/Targets/AArch64.cpp clang/lib/Basic/Targets/AArch64.h Index: clang/lib/Basic/Targets/AArch64.h

[PATCH] D64416: [AArch64] Add support for Transactional Memory Extension (TME)

This revision was automatically updated to reflect the committed changes. Closed by commit rL366322: [AArch64] Add support for Transactional Memory Extension (TME) (authored by chill, committed by ). Herald added a subscriber: kristina. Changed prior to commit: https://reviews.llvm.org/D64416?v

[PATCH] D64416: [AArch64] Add support for Transactional Memory Extension (TME)

chill reopened this revision. chill added a comment. This revision is now accepted and ready to land. I reverted the patch, have to rework `tcancel`. Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64416/new/ https://reviews.llvm.org/D64416 __

[PATCH] D64416: [AArch64] Add support for Transactional Memory Extension (TME)

chill updated this revision to Diff 210768. chill added a comment. This revision is now accepted and ready to land. Changed `tcancel` implementation. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64416/new/ https://reviews.llvm.org/D64416 Files: clang/include/clang/Basic/BuiltinsAArc

[PATCH] D64416: [AArch64] Add support for Transactional Memory Extension (TME)

chill updated this revision to Diff 211140. This revision is now accepted and ready to land. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64416/new/ https://reviews.llvm.org/D64416 Files: clang/include/clang/Basic/BuiltinsAArch64.def clang/lib/Basic/Targets/AArch64.cpp clang/lib/B

[PATCH] D64416: [AArch64] Add support for Transactional Memory Extension (TME)

chill added a comment. If there are no objections, I'll go ahead with committing that Soon(tm) on the basis of previous acceptance. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64416/new/ https://reviews.llvm.org/D64416 ___ cfe-commits ma

[PATCH] D64416: [AArch64] Add support for Transactional Memory Extension (TME)

chill updated this revision to Diff 212332. chill added a comment. Rebase on top of master. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64416/new/ https://reviews.llvm.org/D64416 Files: clang/include/clang/Basic/BuiltinsAArch64.def clang/lib/Basic/Targets/AArch64.cpp clang/lib/

[PATCH] D64416: [AArch64] Add support for Transactional Memory Extension (TME)

This revision was automatically updated to reflect the committed changes. Closed by commit rL367428: [AArch64] Add support for Transactional Memory Extension (TME) (authored by chill, committed by ). Changed prior to commit: https://reviews.llvm.org/D64416?vs=212332&id=212559#toc Repository:

[PATCH] D64410: [WIP] Intrinsics side effects

chill created this revision. Herald added subscribers: llvm-commits, cfe-commits, hiraditya, kristof.beyls, javed.absar. Herald added projects: clang, LLVM. Change-Id: I49f5612ce6899004fa84b9a83c34dcd2d9af8224 Consistent types and naming for AArch64 target features (NFC) Change-Id: I6bac2672de6

[PATCH] D64410: [WIP] Intrinsics side effects

chill abandoned this revision. chill added a comment. I fail at arcanist. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64410/new/ https://reviews.llvm.org/D64410 ___ cfe-commits mailing list cfe-commi

[PATCH] D67542: Fix depfile name construction

chill added a reviewer: chill. chill added inline comments. Comment at: clang/test/Driver/metadata-with-dots.c:2 +// RUN: mkdir -p out.dir +// RUN: cat %s > out.dir/test.c +// RUN: %clang -E -MMD %s -o out.dir/test Is this going to ruin on Windows ? ==

[PATCH] D67542: Fix depfile name construction

chill accepted this revision. chill added a comment. This revision is now accepted and ready to land. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67542/new/ https://reviews.llvm.org/D67542 ___ cfe-commits mailing list cfe-commits@lis

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill created this revision. chill added reviewers: john.brawn, olista01, eli.friedman, rengolin. Herald added a reviewer: javed.absar. Herald added subscribers: chrib, kristof.beyls. The "Procedure Call Procedure Call Standard for the ARM® Architecture" (https://static.docs.arm.com/ihi0042/f/IH

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill added a comment. Ping? Repository: rC Clang https://reviews.llvm.org/D46013 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill added a comment. In https://reviews.llvm.org/D46013#1084440, @efriedma wrote: > I'd like to see some tests for __attribute((packed)). Thanks, indeed it does not work correctly on packed structures. Back to the drawing board ... Repository: rC Clang https://reviews.llvm.org/D46013

[PATCH] D46439: Fix incorrect packed aligned structure layout

chill created this revision. chill added reviewers: rsmith, aaron.ballman. Executing the following program #include #include struct S { char x; int y; } __attribute__((packed, aligned(8))); struct alignas(8) T { char x; int y; } __attribute__((packed)); in

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill updated this revision to Diff 152679. chill added a comment. Update: use "unadjusted alignment" instead of "natural alignment", rename things accordingly. https://reviews.llvm.org/D46013 Files: include/clang/AST/ASTContext.h include/clang/AST/RecordLayout.h lib/AST/ASTContext.cpp

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill added a comment. Ping? https://reviews.llvm.org/D46013 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48916: Fix setting of empty implicit-section-name attribute for functions affected by '#pragma clang section'

chill added inline comments. Comment at: test/CodeGen/clang-sections-attribute.c:1 +// RUN: %clang_cc1 -emit-llvm -triple arm-none-eabi -o - %s | FileCheck %s + Isn't it possible for the test to fail if the Arm target is not configured? Repository: rC Clang

[PATCH] D48916: Fix setting of empty implicit-section-name attribute for functions affected by '#pragma clang section'

chill accepted this revision. chill added a comment. This revision is now accepted and ready to land. LGTM. Please, wait a couple of days before committing to give a chance to someone else to weigh in. Repository: rC Clang https://reviews.llvm.org/D48916 __

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill added a comment. Ping? https://reviews.llvm.org/D46013 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D46013: [ARM] Conform to AAPCS when passing overaligned composites as arguments

chill added a comment. Ping? https://reviews.llvm.org/D46013 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62394: [ARM][CMSE] Add CMSE header & builtins

chill added a comment. I hope I will be able to pick this up in the following weeks and land patches a couple of weeks later. Sorry for the delay, but priorities shift all the time ;) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62394/new/ https://reviews.llvm.org/D62394 __

[PATCH] D68862: [ARM] Allocatable Global Register Variables for ARM

chill added a comment. TBH, I quite dislike the creeping abuse of `SubtargetFeature`s as code generation options. cf. Target.td:1477 //===--===// // SubtargetFeature - A characteristic of the chip set. // IMHO, since r

[PATCH] D68862: [ARM] Allocatable Global Register Variables for ARM

chill added inline comments. Comment at: clang/lib/Basic/Targets/ARM.cpp:902 + std::vector &Features = getTargetOpts().Features; + std::string SearchFeature = "+reserve-" + RegName.str(); + for (std::string &Feature : Features) { SjoerdMeijer wrote: > I was po

[PATCH] D68862: [ARM] Allocatable Global Register Variables for ARM

chill added a comment. In D68862#1708079 , @carwil wrote: > > IMHO, since reserved registes are per-function, this strongly suggests > > implementation as function attribute(s), rather than subtarget features > > (also for the pre-existing r9). > > What

[PATCH] D69297: [ARM][AArch64] Implement __arm_rsrf, __arm_rsrf64, __arm_wsrf & __arm_wsrf64

chill added a comment. I'm a bit unsure how much we're willing to pollute the namespace: in this particular case looking at the four `__bitcast_*` functions. I appreciate that getting rid of them would require emitting LLVM IR bitcasts, so a bit more effort compared to the macro approach. Comm

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

chill added a comment. I don't think this behaviour is correct with regard to the specification (AAELF64 2020Q2): > Static linkers processing ELF relocatable objects must set the feature bit in > the output object or image > only if all the input objects have the corresponding feature bit set.

[PATCH] D82948: [Driver][ARM] Disable unsupported features when nofp arch extension is used

chill added inline comments. Comment at: clang/lib/Driver/ToolChains/Arch/ARM.cpp:476 +// -mfpu=none, -march=armvX+nofp or -mcpu=X+nofp is *very* similar to +// -mfloat-abi=soft, only that it should not disable MVE-I. Features.insert(Features.end(),

[PATCH] D75044: [AArch64] __builtin_return_address for PAuth.

chill added a comment. I'm afraid the patch does not work yet. For example, when the following program void *f() { void g(); g(); return __builtin_return_address(0); } is compiled with ./bin/clang -target aarch64-eabi -march=armv8.3-a -mbranch-protection=pac-ret

[PATCH] D75044: [AArch64] __builtin_return_address for PAuth.

chill added a comment. In D75044#2165496 , @chill wrote: > The issue is that the definition of the instructions `XPAC{D,I}` is > incorrect: it does not mention at all the operand to those insns. Err, they do mention the operand, but only as an input one

[PATCH] D75044: [AArch64] __builtin_return_address for PAuth.

chill accepted this revision. chill added a comment. This revision is now accepted and ready to land. LGTM. Thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75044/new/ https://reviews.llvm.org/D75044 ___ cfe-commits mailing list cfe-co

[PATCH] D82948: [Driver][ARM] Disable unsupported features when nofp arch extension is used

chill accepted this revision. chill added a comment. This revision is now accepted and ready to land. LGTM, thanks! Comment at: clang/lib/Driver/ToolChains/Arch/ARM.cpp:481 +{"-dotprod", "-fp16fml", "-bf16", "-mve.fp"}); +if (!hasIntegerMVE(Features)) {

[PATCH] D75044: [AArch64] __builtin_extract_return_addr for PAuth.

chill added a comment. Needs a test in `clang/test` that `__builtin_extract_return_address` is translated to `llvm.extractreturnaddress`. What if LLVM IR contains a call to `llvm.extractreturnaddress`, but the target is not AArch64? Comment at: llvm/include/llvm/CodeGen/ISDO

[PATCH] D75044: [AArch64] __builtin_extract_return_addr for PAuth.

chill added a comment. In D75044#1966997 , @chill wrote: > Needs a test in `clang/test` that `__builtin_extract_return_address` is > translated to `llvm.extractreturnaddress`. Nevermind, I'm blind. CHANGES SINCE LAST ACTION https://reviews.llvm.org/

[PATCH] D75044: [AArch64] __builtin_extract_return_addr for PAuth.

chill added inline comments. Comment at: clang/lib/CodeGen/TargetInfo.cpp:5151 + return Address; +} +llvm::Function *F = Can drop the extra braces here. Comment at: clang/lib/CodeGen/TargetInfo.cpp:5156 +llvm::CallInst *Call =

[PATCH] D75181: [AArch64] Handle BTI/PAC in case of generated functions.

chill added inline comments. Comment at: clang/lib/CodeGen/TargetInfo.cpp:5149-5152 + if (BPI.BranchTargetEnforcement) +Fn->addFnAttr("branch-target-enforcement", "true"); + else +Fn->addFnAttr("branch-target-enforcement", "false"); -

cfe-commits@lists.llvm.org

chill added inline comments. Comment at: llvm/test/CodeGen/AArch64/aarch64-bf16-ldst-intrinsics.ll:264 +; Function Attrs: argmemonly nounwind readonly +declare { <8 x bfloat>, <8 x bfloat> } @llvm.aarch64.neon.ld2lane.v8bf16.p0i8(<8 x bfloat>, <8 x bfloat>, i64, i8*) #3 + --

cfe-commits@lists.llvm.org

chill added inline comments. Comment at: llvm/test/CodeGen/AArch64/aarch64-bf16-ldst-intrinsics.ll:264 +; Function Attrs: argmemonly nounwind readonly +declare { <8 x bfloat>, <8 x bfloat> } @llvm.aarch64.neon.ld2lane.v8bf16.p0i8(<8 x bfloat>, <8 x bfloat>, i64, i8*) #3 + --

cfe-commits@lists.llvm.org

chill added inline comments. Comment at: llvm/test/CodeGen/AArch64/aarch64-bf16-ldst-intrinsics.ll:264 +; Function Attrs: argmemonly nounwind readonly +declare { <8 x bfloat>, <8 x bfloat> } @llvm.aarch64.neon.ld2lane.v8bf16.p0i8(<8 x bfloat>, <8 x bfloat>, i64, i8*) #3 + --

[PATCH] D81837: [ARM][bfloat] Removing lowering of bfloat arguments and returns from Clang's CodeGen

chill added a comment. Pretty straightforward, LGTM. I'd suggest rewording the title (presumably commit message summary) into something like "Do not coerce bfloat arguments and returns to integers", as we're obviously still lowering C and C++ to LLVM LR.§§ Repository: rG LLVM Github Monorepo

[PATCH] D82948: [Driver][ARM] Disable unsupported features when nofp arch extension is used

chill added a comment. Needs a regression test. This patch and the dependent patch clash, better with a single patch. Comment at: clang/lib/Driver/ToolChains/Arch/ARM.cpp:288 +static void appendNoFPUnsupportedFeatures(const arm::FloatABI ABI, +

[PATCH] D82948: [Driver][ARM] Disable unsupported features when nofp arch extension is used

chill added inline comments. Comment at: clang/lib/Driver/ToolChains/Arch/ARM.cpp:292-297 + auto checkFPDisabledInArchName = [](const StringRef &ArchName) { +SmallVector Split; +ArchName.split(Split, '+', -1, false); +return llvm::any_of( +Split, [](const Str

[PATCH] D82948: [Driver][ARM] Disable unsupported features when nofp arch extension is used

chill added inline comments. Comment at: clang/lib/Driver/ToolChains/Arch/ARM.cpp:292-297 + auto checkFPDisabledInArchName = [](const StringRef &ArchName) { +SmallVector Split; +ArchName.split(Split, '+', -1, false); +return llvm::any_of( +Split, [](const Str

[PATCH] D77270: Fix the check for regparm in FunctionType::ExtInfo

This revision was automatically updated to reflect the committed changes. Closed by commit rG334ac8105401: Fix the check for regparm in FunctionType::ExtInfo (authored by chill). Herald added a project: clang. Herald added a subscriber: cfe-commits. Repository: rG LLVM Github Monorepo CHANGES

[PATCH] D76369: [CMSE] Clear padding bits of struct/unions/fp16 passed by value

This revision was automatically updated to reflect the committed changes. Closed by commit rG102b4105e3fd: [CMSE] Clear padding bits of struct/unions/fp16 passed by value (authored by chill). Herald added a project: clang. Herald added a subscriber: cfe-commits. Repository: rG LLVM Github Monor

[PATCH] D78129: Add Marvell ThunderX3T110 support

chill added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:849-857 +// These pointer authentication instructions require armv8.3a +let Predicates = [HasV8_3a, HasPA] in { let Uses = [LR], Defs = [LR] in { def PACIAZ : SystemNoOperands<0b000, "hint\

[PATCH] D75044: [AArch64] __builtin_return_address for PAuth.

chill requested changes to this revision. chill added a comment. This revision now requires changes to proceed. Let's postpone this just for a little bit, to settle on an approach to `depth > 0`. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75044/new/ https://reviews.llvm.org/D75044

[PATCH] D75044: [AArch64] __builtin_return_address for PAuth.

chill added a comment. In D75044#2186973 , @chill wrote: > Let's postpone this just for a little bit, to settle on an approach to `depth > > 0`. This is with regard to https://reviews.llvm.org/D84502#inline-779900 CHANGES SINCE LAST ACTION https://r

[PATCH] D82949: [Driver][ARM] Disable bf16 when hardware FP support is missing

chill added a comment. Is this patch needed anymore? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82949/new/ https://reviews.llvm.org/D82949 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

chill added a comment. In D80791#2164543 , @danielkiss wrote: >> If any function has the attribute "sign-return-address", then the output note >> section should have PAC bit set. The return address signing is completely >> local >> to the function, and fu

[PATCH] D75181: [AArch64] Handle BTI/PAC in case of generated functions.

chill added a comment. This approach looks way too hackish to me with multiple opposing attributes ("sign-return-address" vs. "ignore-sign-return-address") and some convoluted logic to resolve the contradiction. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75181/new/ https://reviews.l

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

chill added inline comments. Comment at: clang/lib/CodeGen/TargetInfo.cpp:5550 +auto &VMContext = CGM.getLLVMContext(); +M->addModuleFlag(llvm::Module::Override, "sign-return-address", + Scope == LangOptions::SignReturnAddressScopeKind::All

[PATCH] D75181: [AArch64] Handle BTI/PAC in case of generated functions.

chill added a comment. In D75181#2193447 , @danielkiss wrote: > I don't see any other alternative option, I'm open to any other idea. My original idea was to pass options to LLVM. I'll come up with a patch in a day or two (if it works) and then we'll see

[PATCH] D81930: [AArch64] Add -mmark-bti-property flag.

chill requested changes to this revision. chill added inline comments. This revision now requires changes to proceed. Herald added a subscriber: dang. Comment at: llvm/lib/Target/AArch64/AArch64.td:352 +def FeatureEmitNoteBTIProperty : SubtargetFeature<"markbtiproperty", "Mark

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

chill added a comment. In D80791#2196598 , @nsz wrote: > the assumption is that the intended branch protection is implied via cmdline > flags for the tu and function attributes are only used in source code for > some hack. I don't share this assumption.

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

chill added a comment. In D80791#2206853 , @nsz wrote: > i think that cannot work. > > the implementation is free to inject arbitrary code into > user code so if the user does not tell the implementation > that it wants the entire tu to be bti safe then no

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

chill added a comment. I would prefer to avoid the situation where the markings of two otherwise identical files were different, depending on how the files were produced, no matter if it was a common or a special case. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80791/new/ https://r

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

chill added a comment. In D80791#2209624 , @nsz wrote: > In D80791#2207203 , @chill wrote: > >> I would prefer to avoid the situation where the markings of two otherwise >> identical files were different, >> depend

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

chill added a comment. In D80791#2210124 , @danielkiss wrote: >>> it is not useful to have a bti annotated function unless everything else is >>> bti compatible too: it is all or nothing per elf module. >> >> This is false. Some functions in an elf module

[PATCH] D79693: [test][ARM][CMSE] Use -ffreestanding for arm_cmse.h tests

chill added a comment. I'm sorry, I don't understand the issue. Certainly it's the compiler (driver) responsibility to setup include paths according to the selected target. How do you trigger a problem? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/

[PATCH] D79693: [test][ARM][CMSE] Use -ffreestanding for arm_cmse.h tests

chill added a comment. I see. I can also count (`grep -rn '#include.*https://reviews.llvm.org/D79693/new/ https://reviews.llvm.org/D79693 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com

[PATCH] D79693: [test][ARM][CMSE] Use clang_cc1 in arm_cmse.h tests

chill accepted this revision. chill added a comment. This revision is now accepted and ready to land. LGTM, thank you. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79693/new/ https://reviews.llvm.org/D79693 _

[PATCH] D123498: [clang] Adding Platform/Architecture Specific Resource Header Installation Targets

chill added a comment. Should these lists contain only source tree headers or also generated header files? I'm not seeing `arm_mve.h`, for example. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123498/new/ https://reviews.llvm.org/D123498 ___

[PATCH] D119166: [clang][ARM] Re-word PACBTI warning.

chill added inline comments. Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:149 +def warn_incompatible_branch_protection_option: Warning < + "'-mbranch-protection=' option incompatible with the '%0' architecture">, InGroup; "is incompatible"

[PATCH] D119724: Fix test failure for targets with varying uwtable defaults

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGa31d00ddceb0: Fix test failure for targets with varying uwtable defaults (authored by chill). Herald added a project: clang. Herald added a subscribe

[PATCH] D114543: Extend the `uwtable` attribute with unwind table kind

chill added a comment. In D114543#3319347 , @durin42 wrote: > As far as I can tell this patch broke the Rust compiler, but from the commit > message it sounds like it shouldn't have? > > https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/bu

[PATCH] D114543: Extend the `uwtable` attribute with unwind table kind

chill added a comment. In D114543#3319587 , @durin42 wrote: > > Is the parameter optional if uwtable is set programmatically, or only when > we're reading IR streams? No, it's not optional, the attribute is added by https://github.com/llvm/llvm-pro

[PATCH] D114543: Extend the `uwtable` attribute with unwind table kind

chill added inline comments. Comment at: llvm/lib/IR/Attributes.cpp:453 +return "uwtable"; + return ("uwtable(" + Twine(Kind == UWTableKind::Sync ? "sync" : "async") + + ")") RKSimon wrote: > @chill Static analysis is warning that its i

[PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

chill added a comment. Herald added a project: LLVM. Shouldn't we disable `OPT_ffine_grained_bitfield_accesses` only if TSAN is active? Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D36562/new/ https://reviews.llvm.org/D36562 ___

[PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

chill added a comment. In D36562#1641930 , @wmi wrote: > In D36562#1639441 , @chill wrote: > > > Shouldn't we disable `OPT_ffine_grained_bitfield_accesses` only if TSAN is > > active? > > > I don't remember why it

[PATCH] D33676: Place implictly declared functions at block scope

chill added a comment. Ping. https://reviews.llvm.org/D33676 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

  1   2   >