[clang] Resolve FIXME: Look at E, not M (PR #85541)

rjmccall wrote: Hmm. Well, you'd have to ask @zygoloid what he was thinking in r183721/r183859, but I don't think it's correct in general to be looking at E (the MTE sub-expression) for most of the logic here. IIRC, the MTE sub-expression is essentially the initializer for the materialized t

[clang] Resolve FIXME: Look at E, not M (PR #85541)

rjmccall wrote: Well, sometimes we do leave FIXMEs that end up being suprisingly easy to fix. But what FIXME are we talking about here? The patch doesn't remove any FIXMEs, or for that matter include any tests. https://github.com/llvm/llvm-project/pull/85541 _

[clang] [clang] Factor out OpenACC part of `Sema` (PR #84184)

@@ -0,0 +1,74 @@ +//===- SemaOpenACC.h - Semantic Analysis for OpenACC constructs ---===// +// +// 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

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall approved this pull request. Okay. Thanks for putting up with such a protracted review! I really like where we've ended up. LGTM. Please wait a few days before merging to give other reviewers a chance to give final feedback. https://github.com/llvm/llvm-project/p

[clang] [clang][AST][NFC] Add '[[fallthrough]]' to cases fall through (PR #85921)

rjmccall wrote: Yeah, I don't think we need this change. The comment is a little unnecessary, but it's not a big deal. Really, the code ought to be using a visitor instead of a `switch`. https://github.com/llvm/llvm-project/pull/85921 ___ cfe-commi

[clang] Rebase swiftasynccall's musttail support onto the [[clang::musttail]] logic (PR #86011)

https://github.com/rjmccall closed https://github.com/llvm/llvm-project/pull/86011 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Rebase swiftasynccall's musttail support onto the [[clang::musttail]] logic (PR #86011)

https://github.com/rjmccall created https://github.com/llvm/llvm-project/pull/86011 The old logic expects the call to be the last thing we emitted, and since it kicks in before we emit cleanups, and since `swiftasynccall` functions always return void, that's likely to be true. "Likely" isn't

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

@@ -1495,6 +1495,10 @@ Decl *Parser::ParseFunctionDefinition(ParsingDeclarator &D, return Actions.ActOnFinishFunctionBody(Res, nullptr, false); } + // Some function attributes (like OptimizeNoneAttr) affect FP options. + Sema::FPFeaturesStateRAII SaveFPFeatures(Action

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,247 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,247 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,247 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,247 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,247 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/65742 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,247 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,247 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall commented: This looks great, thanks! I have a few editorial nits, and there's an assertion that seems off, but otherwise this looks ready to go. https://github.com/llvm/llvm-project/pull/65742 ___ cfe-commits mailing list

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,247 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang][NFC] Add documentation for `CastExpr::path()`. (PR #85623)

https://github.com/rjmccall approved this pull request. https://github.com/llvm/llvm-project/pull/85623 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

@@ -2508,6 +2508,10 @@ Decl *Parser::ParseFunctionStatementBody(Decl *Decl, ParseScope &BodyScope) { Sema::PragmaStackSentinelRAII PragmaStackSentinel(Actions, "InternalPragmaState", IsCXXMethod); + // Some function attributes (like OptimizeNoneAttr) affect FP options.

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

https://github.com/rjmccall commented: Alright. I don't really have a problem with doing this, and this seems like basically the right approach. You're applying the attributes in the wrong place, though. https://github.com/llvm/llvm-project/pull/85605

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/85605 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][NFC] Add documentation for `CastExpr::path()`. (PR #85623)

@@ -3552,6 +3552,15 @@ class CastExpr : public Expr { /// function that it invokes. NamedDecl *getConversionFunction() const; + /// Path through the class hierarchy taken by a `DerivedToBase` or + /// `UncheckedDerivedToBase` cast. For each derived-to-base edge in the pa

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

rjmccall wrote: > > Hmm. Is there some sort of optimization in IRGen that we need to suppress > > here, or is it something in LLVM code gen? Presumably normal LLVM > > optimization passes all just skip `optnone` functions. > > The issue #62098 demonstrates such case. Okay. So if I understand

[clang] [clang] Add `__has_extension(swiftcc)` support (PR #85347)

https://github.com/rjmccall approved this pull request. Yeah, it's fine with me. https://github.com/llvm/llvm-project/pull/85347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Better bitfield access units (PR #65742)

rjmccall wrote: Yeah, we don't need to care about the actual bit offset of the zero-width bit-field as long as we honor the non-interference properties across it. I'll take a look at the patch, thanks. https://github.com/llvm/llvm-project/pull/65742 ___

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

rjmccall wrote: Hmm. Is there some sort of optimization in IRGen that we need to suppress here, or is it something in LLVM code gen? Presumably normal LLVM optimization passes all just skip `optnone` functions. Mostly I'm wondering how far we're expected to go with `optnone`. https://github

[clang] [llvm] [AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (PR #65996)

@@ -0,0 +1,265 @@ +Pointer Authentication +== + +.. contents:: + :local: + +Introduction + + +Pointer authentication is a technology which offers strong probabilistic protection against exploiting a broad class of memory bugs to take control of

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/65742 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/65742 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,194 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/65742 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/65742 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,194 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,194 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,194 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/65742 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,194 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,194 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,194 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,194 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,194 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

@@ -439,82 +444,194 @@ CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset), MemberInfo::Field, nullptr, *Field)); } -return; +return Field;

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall commented: Thank you, the structure looks great! Mostly style and clarity comments from here. https://github.com/llvm/llvm-project/pull/65742 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/c

[clang] [clang] Stub out gcc_struct attribute (PR #71148)

rjmccall wrote: > @rjmccall Re asking GCC developers about gcc_struct on non-x86: > https://gcc.gnu.org/pipermail/gcc/2024-January/243154.html. Either GCC devs > aren't really worried about this or I can't properly write emails (what's > totally possible). Alright, well, we tried. I think ro

[clang] [clang][Sema] Add noinline check for __builtin_frame_address and __builtin_return_address (PR #82966)

rjmccall wrote: > I'm seeing evidence that this might be a chatty diagnostic in practice: > > https://sourcegraph.com/github.com/torvalds/linux@90d35da658da8cff0d4ecbb5113f5fac9d00eb72/-/blob/kernel/fork.c?L311 > > https://sourcegraph.com/github.com/torvalds/linux@90d35da658da8cff0d4ecbb5113f5

[clang] [clang] Better bitfield access units (PR #65742)

@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() { : getStorageType(*Field), *Field)); ++Field; -} else { - ++Field; } } } -void -CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, -

[clang] [clang] Better bitfield access units (PR #65742)

@@ -858,6 +861,10 @@ class TargetInfo : public TransferrableTargetInfo, return PointerWidth; } + /// Return true, iff unaligned accesses are a single instruction (rather than rjmccall wrote: ```suggestion /// Return true iff unaligned accesses are a

[clang] [clang] Better bitfield access units (PR #65742)

@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() { : getStorageType(*Field), *Field)); ++Field; -} else { - ++Field; } } } -void -CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, -

[clang] [clang] Better bitfield access units (PR #65742)

@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() { : getStorageType(*Field), *Field)); ++Field; -} else { - ++Field; } } } -void -CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, -

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/65742 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Better bitfield access units (PR #65742)

https://github.com/rjmccall commented: I think using the existing information as a default is fine, but please continue to call the hook something like `hasCheapUnalignedAccess()` to preserve the intent, even if it always just calls the other hook. https://github.com/llvm/llvm-project/pull/657

[clang] [cfi][CodeGen] Call SetLLVMFunctionAttributes{, ForDefinition} on __cf… (PR #78253)

https://github.com/rjmccall approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/78253 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [ObjC] Check entire chain of superclasses to see if class layout is statically known (PR #81335)

https://github.com/rjmccall approved this pull request. Thanks, that looks great. https://github.com/llvm/llvm-project/pull/81335 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Better bitfield access units (PR #65742)

rjmccall wrote: > > On the target hook, it's a shame we can't easily get this information from > > LLVM. I believe it's already there — `TargetLowering` has an > > `allowsMisalignedMemoryAccesses` method that includes some approximation of > > how fast a particular access would be. In practice

[clang] [ObjC] Check entire chain of superclasses to see if class layout can be statically known (PR #81335)

@@ -1,6 +1,12 @@ // RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 -emit-llvm %s -o - | FileCheck %s // CHECK: @"OBJC_IVAR_$_StaticLayout.static_layout_ivar" = hidden constant i64 20 +// CHECK: @"OBJC_IVAR_$_SuperClass.superClassIvar" = hidden constant i64 20 ---

[clang] [ObjC] Check entire chain of superclasses to see if class layout can be statically known (PR #81335)

@@ -17,9 +23,71 @@ @implementation StaticLayout { -(void)meth { static_layout_ivar = 0; // CHECK-NOT: load i64, ptr @"OBJC_IVAR_$_StaticLayout + // CHECK: getelementptr inbounds i8, ptr %0, i64 20 } @end +// Ivars declared in the @interface +@interface SuperClass : NSO

[clang] [ObjC] Check entire chain of superclasses to see if class layout can be statically known (PR #81335)

@@ -1,6 +1,12 @@ // RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 -emit-llvm %s -o - | FileCheck %s // CHECK: @"OBJC_IVAR_$_StaticLayout.static_layout_ivar" = hidden constant i64 20 +// CHECK: @"OBJC_IVAR_$_SuperClass.superClassIvar" = hidden constant i64 20 +// CHECK:

[clang] [ObjC] Check entire chain of superclasses to see if class layout can be statically known (PR #81335)

https://github.com/rjmccall commented: Thanks, the breadth of tests looks good. Please improve the actual testing, though — CHECK lines are testing the IR output file at a whole, so now that there are multiple tests in this file, we really need to make these tests more specific. - First, ple

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

rjmccall wrote: > @rjmccall fixed feedback > > > You should handle compound assignments. > > I believe I already support compound assignments (and PrePostIncDec), if I am > not missing something? 😃 Ah, maybe you are, sorry. I was expecting it in `CGExpr.cpp` and forgot that that code was ac

[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)

rjmccall wrote: There's no such thing as "this is impossible to do". Clang, as the frontend, is responsible for emitting IR that has gets the effect we want. If that means contorting the IR we generate to do ugly things like memcpying into a temporary, that's our life. I am not surprised th

[clang] [compiler-rt] [Sanitizer] add signed-integer-wrap sanitizer (PR #80089)

rjmccall wrote: > > > > Why not just enforce -fsanitize=signed-integer-overflow with -fwrapv? I > > > > suspect it's just overlook, and not intentional behavior. > > > > > > > > > +1 > > > We should consider this direction > > > > > > The UB-vs-non-UB seemed to be a really specific goal in t

[clang] [compiler-rt] [Sanitizer] add signed-integer-wrap sanitizer (PR #80089)

https://github.com/rjmccall commented: Yeah, LGTM. https://github.com/llvm/llvm-project/pull/80089 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -122,6 +122,26 @@ Non-comprehensive list of changes in this release New Compiler Flags -- +- ``-fsanitize=implicit-unsigned-bitfield-truncation`` catches implicit + unsigned conversions involving bitfields. +- ``-fsanitize=implicit-signed-bitfield-truncatio

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

https://github.com/rjmccall commented: You should handle compound assignments. https://github.com/llvm/llvm-project/pull/75481 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -5570,11 +5570,44 @@ LValue CodeGenFunction::EmitBinaryOperatorLValue(const BinaryOperator *E) { break; } -RValue RV = EmitAnyExpr(E->getRHS()); +llvm::Value *Previous = nullptr; +RValue RV; +QualType SrcType = E->getRHS()->getType(); +// If L

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -1097,6 +1112,27 @@ void ScalarExprEmitter::EmitIntegerTruncationCheck(Value *Src, QualType SrcType, {Src, Dst}); } +static llvm::Value *EmitIsNegativeTestHelper(Value *V, QualType VType, + const char *Name, +

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -324,6 +326,19 @@ class ScalarExprEmitter void EmitIntegerSignChangeCheck(Value *Src, QualType SrcType, Value *Dst, QualType DstType, SourceLocation Loc); + /// Emit a check that an [implicit] truncation of a bitfield does not + /// dis

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -5570,11 +5570,44 @@ LValue CodeGenFunction::EmitBinaryOperatorLValue(const BinaryOperator *E) { break; } -RValue RV = EmitAnyExpr(E->getRHS()); +llvm::Value *Previous = nullptr; +RValue RV; +QualType SrcType = E->getRHS()->getType(); +// If L

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -1097,6 +1112,27 @@ void ScalarExprEmitter::EmitIntegerTruncationCheck(Value *Src, QualType SrcType, {Src, Dst}); } +static llvm::Value *EmitIsNegativeTestHelper(Value *V, QualType VType, + const char *Name, +

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -1239,6 +1257,228 @@ void ScalarExprEmitter::EmitIntegerSignChangeCheck(Value *Src, QualType SrcType, {Src, Dst}); } +// Should be called within CodeGenFunction::SanitizerScope RAII scope. +// Returns 'i1 false' when the truncation Src -> Dst was lossy. +st

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -1035,7 +1050,7 @@ EmitIntegerTruncationCheckHelper(Value *Src, QualType SrcType, Value *Dst, } llvm::Value *Check = nullptr; - // 1. Extend the truncated value back to the same width as the Src. + // 1. Convert the Dst back to the same type as Src.

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/75481 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Vector standard conversions (PR #71098)

https://github.com/rjmccall approved this pull request. Thanks, LGTM https://github.com/llvm/llvm-project/pull/71098 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Better bitfield access units (PR #65742)

rjmccall wrote: > @rjmccall thanks for your comments. Here's a reimplementation using a single > loop -- the downside is that we may end up repeating the initial grouping > scan, if we search more than 1 Access Unit ahead and fail to find a 'good' > access unit. This update changes the algorit

[clang] [HLSL] Vector standard conversions (PR #71098)

@@ -361,6 +361,9 @@ CAST_OPERATION(AddressSpaceConversion) // Convert an integer initializer to an OpenCL sampler. CAST_OPERATION(IntToOCLSampler) +// Truncate a vector type (HLSL only). +CAST_OPERATION(HLSLVectorTruncation) rjmccall wrote: Okay. I think thi

[clang] [ObjC] Check entire chain of superclasses to see if class layout can be statically known (PR #81335)

rjmccall wrote: > Alright. I think the LTO should be done as a follow-up PR since it will > likely take some time and multiple reviews to get right. Yes, that's a fine plan. I expect that that'll be a significant amount of work. https://github.com/llvm/llvm-project/pull/81335

[clang] [ObjC] Check entire chain of superclasses to see if class layout can be statically known (PR #81335)

https://github.com/rjmccall requested changes to this pull request. > @rjmccall Are these tests adequate? No. You need to test the behavior of ivar accesses in the subclass when there is an intermediate superclass that has ivars declared in all the ways I identified. Your test has many tests

[clang] [clang] Add some CodeGen tests for CWG 2xx issues (PR #80823)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/80823 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add some CodeGen tests for CWG 2xx issues (PR #80823)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/80823 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add some CodeGen tests for CWG 2xx issues (PR #80823)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/80823 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add some CodeGen tests for CWG 2xx issues (PR #80823)

@@ -0,0 +1,43 @@ +// RUN: %clang_cc1 -std=c++98 %s -triple x86_64-linux-gnu -emit-llvm -disable-llvm-passes -O0 -o - -fexceptions -fcxx-exceptions -pedantic-errors | llvm-cxxfilt -n | FileCheck %s --check-prefixes CHECK +// RUN: %clang_cc1 -std=c++11 %s -triple x86_64-linux-gnu

[clang] [ObjC] Check entire chain of superclasses to see if class layout can be statically known (PR #81335)

rjmccall wrote: I talked this over with Mike Ash. I was concerned that Objective-C might allow dynamic class changes that would burn our ability to do this optimization, such as adding ivars during `+initialize`. The existing optimization would work even with a relatively lax runtime as long

[clang] [ObjC] Check entire chain of superclasses to see if class has fixed offsets (PR #81335)

https://github.com/rjmccall requested changes to this pull request. Okay, your description of the change here is very misleading; it doesn't even mention that this is specific to having an `@implementation` for every intermediate class. Your test seems completely inadequate — you need to test

[clang] [clang][Sema] Subclass `-Wshorten-64-to-32` under `-Wimplicit-int-conversion` (PR #80814)

rjmccall wrote: This looks right to me, thanks. https://github.com/llvm/llvm-project/pull/80814 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang] [llvm] [HLSL] Vector standard conversions (PR #71098)

rjmccall wrote: Argh, sorry for the slow response. https://github.com/llvm/llvm-project/pull/71098 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang] [llvm] [HLSL] Vector standard conversions (PR #71098)

@@ -2414,9 +2420,41 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) { return EmitScalarConversion(Visit(E), E->getType(), DestTy, CE->getExprLoc(), Opts); } - case CK_IntegralToFloating: - case CK_FloatingToIntegral: - case CK_F

[llvm] [clang] [clang-tools-extra] [HLSL] Vector standard conversions (PR #71098)

@@ -361,6 +361,9 @@ CAST_OPERATION(AddressSpaceConversion) // Convert an integer initializer to an OpenCL sampler. CAST_OPERATION(IntToOCLSampler) +// Truncate a vector type (HLSL only). +CAST_OPERATION(HLSLVectorTruncation) rjmccall wrote: Unfortunately, we

[clang-tools-extra] [clang] [llvm] [HLSL] Vector standard conversions (PR #71098)

@@ -1843,13 +1843,86 @@ bool Sema::IsFunctionConversion(QualType FromType, QualType ToType, return true; } +/// Determine whether the conversion from FromType to ToType is a valid +/// floating point conversion. +/// +static bool IsFloatingPointConversion(Sema &S, QualType

[llvm] [clang] [clang-tools-extra] [HLSL] Vector standard conversions (PR #71098)

@@ -2466,6 +2504,15 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) { case CK_IntToOCLSampler: return CGF.CGM.createOpenCLIntToSamplerConversion(E, CGF); + case CK_HLSLVectorTruncation: { +assert(DestTy->isVectorType() && "Expected dest type to be vector ty

[clang] [clang][CodeGen][UBSan] Fixing shift-exponent generation for _BitInt (PR #80515)

rjmccall wrote: > One thing I'll preemptively address is I didn't know where to put the new > unit testing - creating a separate file seems a little heavy handed but I see > that there's a test for UBSan shift generation > (`clang/test/CodeGen/ubsan-shift.c`) and one for UBSan + _BitInt > (`c

[clang] [FPEnv] Add strictfp in some C++ constructors lacking a FunctionDecl. (PR #74883)

https://github.com/rjmccall requested changes to this pull request. I'm sorry for failing to notice this in my previous review, but I don't think this patch is right. A global initializer should be FP-constrained based on whether the variable is defined in an FP-constrained context. This is t

[libunwind] [clang-tools-extra] [libc] [flang] [llvm] [lld] [libcxx] [clang] [compiler-rt] [lldb] [libcxxabi] Fix a bug in Smith's algorithm used in complex div. (PR #78330)

rjmccall wrote: If LLVM wants to provide intrinsics that cover patterns that the frontend wants to emit, that'd be great. The frontend will still have to make decisions about e.g. whether to request Smith's algorithm, of course. https://github.com/llvm/llvm-project/pull/78330

[clang] [clang-tools-extra] [libc] [llvm] [libcxxabi] [libcxx] [lld] [flang] [libunwind] [lldb] [compiler-rt] Fix a bug in Smith's algorithm used in complex div. (PR #78330)

rjmccall wrote: > > This is unrelated, but I wonder if we should proactively outline this > > sequence; it's quite long. > > Not sure what you mean. I mean that we could lazily emit a helper function like `__clang_smiths_division_double` and call it instead of emitting like twenty instructio

[clang] [llvm] [libc] [libcxx] [compiler-rt] [lldb] [flang] [clang-tools-extra] [libunwind] [libcxxabi] [lld] Fix a bug in Smith's algorithm used in complex div. (PR #78330)

https://github.com/rjmccall approved this pull request. LGTM as far as my requests; please wait for approval from the other reviewers. This is unrelated, but I wonder if we should proactively outline this sequence; it's quite long. https://github.com/llvm/llvm-project/pull/78330 __

[clang-tools-extra] [libc] [lld] [llvm] [flang] [libcxxabi] [clang] [libunwind] [libcxx] [compiler-rt] [lldb] Fix a bug in Smith's algorithm used in complex div/mul. (PR #78330)

https://github.com/rjmccall commented: It's bad that we don't have a IR test that breaks when you change the IR output like this. Please add one. https://github.com/llvm/llvm-project/pull/78330 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[libc] [lldb] [clang] [llvm] [libunwind] [flang] [lld] [libcxxabi] [clang-tools-extra] [libcxx] [compiler-rt] Fix a bug in Smith's algorithm used in complex div/mul. (PR #78330)

@@ -978,7 +978,11 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const BinOpInfo &Op) { return EmitRangeReductionDiv(LHSr, LHSi, RHSr, RHSi); else if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Limited) return EmitAlgebraicDiv(LHSr, LHSi, RHSr, RHSi);

[libcxx] [flang] [lldb] [clang-tools-extra] [libc] [libunwind] [libcxxabi] [clang] [llvm] [compiler-rt] [lld] Fix a bug in Smith's algorithm used in complex div/mul. (PR #78330)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/78330 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix behavior of `__is_trivially_relocatable(volatile int)` (PR #77092)

@@ -2669,6 +2669,8 @@ bool QualType::isTriviallyRelocatableType(const ASTContext &Context) const { return false; } else if (const auto *RD = BaseElementType->getAsRecordDecl()) { return RD->canPassInRegisters(); + } else if (BaseElementType.isTriviallyCopyableType(C

[clang] [Clang] Set writable and dead_on_unwind attributes on sret arguments (PR #77116)

https://github.com/rjmccall approved this pull request. https://github.com/llvm/llvm-project/pull/77116 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

<    1   2   3   4   5   6   7   8   9   >