https://github.com/rjmccall approved this pull request.
This LGTM. Please reach out to the Fuchsia and XL folks if you can, but we
don't need to hold up the PR over it.
https://github.com/llvm/llvm-project/pull/90462
___
cfe-commits mailing list
@@ -2415,46 +2415,112 @@ DiagnosticBuilder
ItaniumRecordLayoutBuilder::Diag(SourceLocation Loc,
return Context.getDiagnostics().Report(Loc, DiagID);
}
+/// https://itanium-cxx-abi.github.io/cxx-abi/abi.html#POD
+/// POD for the purpose of layout
+/// In general, a type
@@ -2415,46 +2415,112 @@ DiagnosticBuilder
ItaniumRecordLayoutBuilder::Diag(SourceLocation Loc,
return Context.getDiagnostics().Report(Loc, DiagID);
}
+/// https://itanium-cxx-abi.github.io/cxx-abi/abi.html#POD
+/// POD for the purpose of layout
+/// In general, a type
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/85886
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall commented:
I think you're right about the intended logic being to check for a definition,
especially given the wording of the warning. IIRC, we didn't have some of
these high-level checks at the time.
With that said, I think you need to check if a definition
rjmccall wrote:
My experience is that compiler writers are really good at hacking in special
cases to make their test cases work and really bad at recognizing that their
case isn't as special as they think. There are three types already called out
for special treatment in
rjmccall wrote:
If you want to do things that way, you will need to (1) generalize CodeGenTypes
with a new API that will return this load/store type when applicable and (2)
look at all the places we call `ConvertTypeForMem`, `EmitToMemory`, and
`EmitFromMemory` to make sure they do the right
rjmccall wrote:
Hmm. I think this is actually pretty different from the `bool` pattern.
Suppose we're talking about `_BitInt(N)`. Let `BYTES := ceil(N/8)`, and let
`BITS := BYTES * 8`.
The problem being presented here is this:
1. For at least some values of `N`, we cannot use LLVM's `iN`
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/90329
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall commented:
The Apple fork does actually use this downstream (for address-sensitive
`__ptrauth`), and we've recently (finally) been making progress in upstreaming
that work. Obviously, we could delete it and then reinstate it when we catch
up to this point in
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the
rjmccall wrote:
Great, thanks! @Midar, if you can fix this code up so that these strings are
created in one place (and test the new output, since this is not NFC), I'd be
happy to sign off.
https://github.com/llvm/llvm-project/pull/88713
___
https://github.com/rjmccall approved this pull request.
This seems fine. Is there any existing bookkeeping we no longer need to do if
we're going to have this RAII object in scope during function parsing?
https://github.com/llvm/llvm-project/pull/85605
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/88713
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall commented:
At first, I was worried that this was an ABI break. Then I noticed the
internal inconsistency within this single file, and so I became worried that it
was an ABI *fix*. But then I noticed that the normal selector-emission code
actually makes these
rjmccall wrote:
> Ah, okay, thank you! I had two concerns, but I think neither are valid now
> that I better understand how `ExtQuals` works: 1) I thought we were
> increasing the in-memory size of `Qualifiers` in a way that matter (like
> `SplitQualType`, `ExtProtoInfo` primarily),
AFAIK,
rjmccall wrote:
> > @AaronBallman See test results from compile-time-tracker here:
> > https://llvm-compile-time-tracker.com/compare.php?from=693a458287d019c5c6a66fe3019d099df2978cdb=dbb5e29d136a18060ba6759b328ad80fa9cea649.
> > It looks like that there is a statistically meaningful difference,
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/87090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
It's my patch, so me signing off isn't very meaningful.
https://github.com/llvm/llvm-project/pull/84384
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2216,7 +2216,7 @@ static llvm::Value *EmitTypeidFromVTable(CodeGenFunction
, const Expr *E,
}
llvm::Value *CodeGenFunction::EmitCXXTypeidExpr(const CXXTypeidExpr *E) {
- llvm::Type *PtrTy = llvm::PointerType::getUnqual(getLLVMContext());
+ llvm::Type *PtrTy =
rjmccall wrote:
> Libcall emission needs to know what AS to use for pointer arguments to things
> like __sync/__atomic implementations and various string-y mem*/str*
> functions. That's the main one that comes to mind from our experience in
> CHERI LLVM, and current LLVM just assumes that's
rjmccall wrote:
> I'm not quite sure how to parse this comment, could you explain what you have
> in mind here? The problem is precisely that the FE assumes 0 is fine / picks
> it by default, which ends up into dangerzones when e.g. a target happened to
> use 0 to point to private (stack). I
rjmccall wrote:
> Why can't we just declare that the "generic" address-space must always be 0?
> The specific numbers we use for address-spaces are completely arbitrary
> anyway.
I don't think this works; there's nothing that LLVM could possibly do with a
generic AS that would justify it
rjmccall wrote:
It's very uncommon for LLVM to need to come up with an address space on its
own, as opposed to just propagating the original address space of some memory /
operation as chosen by the frontend. LLVM occasionally creates new storage
allocations, but usually they're
rjmccall wrote:
It'll be tested in a follow-up commit which actually adds parsing and Sema
support for these as qualifiers. That should be sufficient rather than adding
a whole unit-test apparatus. Daniil is just trying to avoid landing this in a
single massive commit.
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/87238
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall approved this pull request.
Doing in in one commit this time seems fine.
https://github.com/llvm/llvm-project/pull/87238
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
rjmccall wrote:
Hmm. The best solution there is probably to use a consistent representation
but introduce some sort of `GLValueThatTheStandardAbsurdlyPretendsIsAnRValue`
(definitely the only and best word for this, ship it) that we can use as the
value category. IIRC, something similar
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
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
@@ -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:
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.
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
___
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
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
@@ -1495,6 +1495,10 @@ Decl *Parser::ParseFunctionDefinition(ParsingDeclarator
,
return Actions.ActOnFinishFunctionBody(Res, nullptr, false);
}
+ // Some function attributes (like OptimizeNoneAttr) affect FP options.
+ Sema::FPFeaturesStateRAII
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
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
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
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
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
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
@@ -2508,6 +2508,10 @@ Decl *Parser::ParseFunctionStatementBody(Decl *Decl,
ParseScope ) {
Sema::PragmaStackSentinelRAII
PragmaStackSentinel(Actions, "InternalPragmaState", IsCXXMethod);
+ // Some function attributes (like OptimizeNoneAttr) affect FP options.
+
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
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
@@ -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
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
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
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
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`.
@@ -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
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
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
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
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
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
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
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
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
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
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
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
>
>
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
@@ -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
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
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
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/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
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
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
@@ -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
@@ -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 :
@@ -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:
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,
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
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
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
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
@@ -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.
+-
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
@@ -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
@@ -1097,6 +1112,27 @@ void ScalarExprEmitter::EmitIntegerTruncationCheck(Value
*Src, QualType SrcType,
{Src, Dst});
}
+static llvm::Value *EmitIsNegativeTestHelper(Value *V, QualType VType,
+ const char *Name,
+
@@ -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
+ ///
@@ -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
1 - 100 of 667 matches
Mail list logo
