rjmccall added inline comments.
Comment at: include/clang/Basic/DiagnosticSemaKinds.td:259
@@ +258,3 @@
+def err_anyx86_interrupt_attribute : Error<
+ "interrupt service routine %select{must have 'void' return value|"
+ "can only have a pointer argument and an optional integer a
Author: rjmccall
Date: Wed Jan 6 16:34:54 2016
New Revision: 256983
URL: http://llvm.org/viewvc/llvm-project?rev=256983&view=rev
Log:
Only instantiate a default argument once.
By storing the instantiated expression back in the ParmVarDecl,
we remove the last need for separately storing the sub-e
Author: rjmccall
Date: Wed Jan 6 17:34:20 2016
New Revision: 256996
URL: http://llvm.org/viewvc/llvm-project?rev=256996&view=rev
Log:
Properly bind up any cleanups in an ExprWithCleanups after
instantiating a default argument expression.
This was previously just working implicitly by reinstantia
> On Jan 6, 2016, at 3:54 PM, Richard Smith wrote:
> On Wed, Jan 6, 2016 at 3:34 PM, John McCall via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Author: rjmccall
> Date: Wed Jan 6 17:34:20 2016
> New Revision: 256996
>
> URL: http://llvm.org/viewv
rjmccall added a comment.
Sorry, holidays. I'm comfortable with taking this patch as-is.
http://reviews.llvm.org/D14980
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall added a comment.
Yes, this seems to be exactly what I wanted, thanks! LGTM.
http://reviews.llvm.org/D15686
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall added inline comments.
Comment at: include/clang/Basic/TargetInfo.h:385
@@ +384,3 @@
+ unsigned getFloat128Width() const { return Float128Width; }
+ unsigned getFloat128Align() const { return Float128Align; }
+ const llvm::fltSemantics &getFloat128Format() const {
rjmccall added a comment.
Well, that's certainly an interesting ABI rule.
A few high-level notes:
1. AAPCS requires the bit-field to be loaded on a store, even if the store
fills the entire container; that doesn't seem to be implemented in your patch.
2. Especially because of #1, let's not do
rjmccall added a comment.
In http://reviews.llvm.org/D15120#336282, @nemanjai wrote:
> Addressed review comments.
> The key differences are:
>
> - No assignments or operations between entities of long double and __float128
> allowed if the two types have a different representation
> - Each type
rjmccall added a comment.
In http://reviews.llvm.org/D15120#336776, @hubert.reinterpretcast wrote:
> In http://reviews.llvm.org/D15120#336430, @rjmccall wrote:
>
> > As I understand it, PPC's long-double (~103 bits of precision) is still
> > strictly less precise than float128_t (113 bits of pre
rjmccall added a comment.
In http://reviews.llvm.org/D15120#336855, @hubert.reinterpretcast wrote:
> In http://reviews.llvm.org/D15120#336827, @rjmccall wrote:
>
> > Here's the thing, though: I don't think there's a reasonable language
> > solution here besides saying that float128_t has higher
rjmccall added a comment.
In http://reviews.llvm.org/D15120#336996, @hubert.reinterpretcast wrote:
> In http://reviews.llvm.org/D15120#336891, @rjmccall wrote:
>
> > > The C committee decided that "undefined behavior" was what they could
> > > agree on for this sort of case.
> >
> >
> > That's o
rjmccall added a comment.
I think it's not unlikely that float128_t will see future standardization (as
an optional extension, of course), and it would be strange for an operation
between two types to not consistently yield the type of higher rank.
I could see an argument that we should not tre
rjmccall added a comment.
Seems reasonable.
http://reviews.llvm.org/D16607
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: rjmccall
Date: Wed Jan 27 12:32:30 2016
New Revision: 258962
URL: http://llvm.org/viewvc/llvm-project?rev=258962&view=rev
Log:
Emit calls to objc_unsafeClaimAutoreleasedReturnValue when
reclaiming a call result in order to ignore it or assign it
to an __unsafe_unretained variable. This av
rjmccall added a comment.
In http://reviews.llvm.org/D15120#337552, @hubert.reinterpretcast wrote:
> In http://reviews.llvm.org/D15120#337384, @rjmccall wrote:
>
> > I think it's not unlikely that float128_t will see future standardization
> > (as an optional extension, of course), and it would
rjmccall added a comment.
In http://reviews.llvm.org/D15120#337975, @hubert.reinterpretcast wrote:
> In http://reviews.llvm.org/D15120#337654, @rjmccall wrote:
>
> > In http://reviews.llvm.org/D15120#337552, @hubert.reinterpretcast wrote:
> >
> > > It remains that the present standardization effo
Author: rjmccall
Date: Thu Nov 12 17:39:39 2015
New Revision: 252971
URL: http://llvm.org/viewvc/llvm-project?rev=252971&view=rev
Log:
Remove -Wobjc-weak-compat; there isn't a compelling use case for this.
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/S
Author: rjmccall
Date: Mon Nov 16 16:11:41 2015
New Revision: 253255
URL: http://llvm.org/viewvc/llvm-project?rev=253255&view=rev
Log:
Correctly handle type mismatches in the __weak copy/move-initialization
peephole I added in r250916.
rdar://23559789
Added:
cfe/trunk/test/CodeGenObjC/arc-we
rjmccall added inline comments.
Comment at: include/clang/Basic/LangOptions.def:194
@@ -193,2 +193,3 @@
LANGOPT(ObjCAutoRefCount , 1, 0, "Objective-C automated reference counting")
+LANGOPT(ObjCConvertMessagesToRuntimeCalls , 1, 0, "objc_* support for
retain/release in t
rjmccall added a comment.
In http://reviews.llvm.org/D14737#291481, @stephanemoore wrote:
> I hope that it's not presumptuous of me to inquire but I was wondering if the
> intent of this patch is to optimize calls to RR methods (and alloc) in
> non-ARC code? Would I be correct in assuming that
rjmccall added inline comments.
Comment at: include/clang/Basic/ObjCRuntime.h:182
@@ +181,3 @@
+switch (getKind()) {
+case FragileMacOSX: return false;
+case MacOSX: return getVersion() >= VersionTuple(10, 10);
I went ahead and asked Greg, and he agree
rjmccall added a comment.
What I was thinking was something more along the lines of a little struct that
stored either a Decl * or a FunctionType *, and you could change the TargetDecl
argument to functions like EmitCall and ConstructAttributeList to that. Maybe
call it something like CalleeIn
Author: rjmccall
Date: Wed Nov 18 20:27:55 2015
New Revision: 253533
URL: http://llvm.org/viewvc/llvm-project?rev=253533&view=rev
Log:
Fix the emission of ARC-style ivar layouts in the fragile runtime
to start at the offset of the first ivar instead of the rounded-up
end of the superclass. The la
Author: rjmccall
Date: Wed Nov 18 20:28:03 2015
New Revision: 253534
URL: http://llvm.org/viewvc/llvm-project?rev=253534&view=rev
Log:
Don't actually add the __unsafe_unretained qualifier in MRC;
driving a canonical difference between that and an unqualified
type is a really bad idea when both are
rjmccall added a comment.
That's exactly what I was looking for, thanks.
Comment at: lib/CodeGen/CGExpr.cpp:3751
@@ +3750,3 @@
+ // Preserve the function proto type because it contains useful information
+ // that we may be interested in using later on in the code generation.
rjmccall added inline comments.
Comment at: lib/Sema/SemaPseudoObject.cpp:1627
@@ -1579,1 +1626,3 @@
+cast(Base->IgnoreParens())->getBaseExpr());
+return MSPropertyRefRebuilder(S, BaseOVE->getSourceExpr()).rebuild(E);
} else {
Hmm. Just like the Ob
rjmccall added a comment.
Thanks, that's great. One minor tweak, and feel free to just commit when
you've done that.
Comment at: lib/CodeGen/CGCall.cpp:1420
@@ +1419,3 @@
+ // If we have information about the function proto type, we can learn
+ // attributes form there.
+ A
rjmccall added a comment.
By "in CGObjC", I mean you should be able to do it in
CodeGenFunction::EmitObjCMessageExpr. Maybe put it in a separate function like
static llvm::Value *tryGenerateSpecializedMessageSend(...)
and then do something like
} else if (llvm::Value *SpecializedResult =
rjmccall added a comment.
The casts done by emitARCValueOperation will handle the input, but they don't
quite handle the result properly. The right test case here is a method named
"retain" that's declared to return something completely unrelated to its
receiver type, e.g.
@class A;
@inte
rjmccall added a comment.
In http://reviews.llvm.org/D14737#293967, @pete wrote:
> Added a couple of tests for retain returning types other than id. Returning
> a pointer should still be converted to a call, while returning a non-pointer
> such as float will get a message instead.
>
> I walked
rjmccall added inline comments.
Comment at: lib/Sema/SemaPseudoObject.cpp:57
@@ +56,3 @@
+ // with a base limits the number of cases here.
+ assert(refExpr->isObjectReceiver());
+
Well, it should be okay to call this on something that doesn't have a base
rjmccall added inline comments.
Comment at: lib/CodeGen/TargetInfo.cpp:3548
@@ +3547,3 @@
+llvm::Value *OverflowArgArea = OverflowArea.getPointer();
+uint32_t Align = CGF.getContext().getTypeAlignInChars(Ty).getQuantity();
+if (Align > 4) {
This patch
rjmccall added a comment.
This looks fantastic, thanks for doing all that. Approved with the one minor
change.
Comment at: lib/Sema/SemaPseudoObject.cpp:175
@@ -145,1 +174,3 @@
+PSE->getType(), PSE->getValueKind(), PSE->getObjectKind(),
+PSE->getRBracke
rjmccall added a comment.
LGTM.
http://reviews.llvm.org/D14864
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall added inline comments.
Comment at: lib/CodeGen/TargetInfo.cpp:241
@@ +240,3 @@
+ return Address(PtrAsInt, Align);
+}
+
Thank you for extracting this.
First, this function deserves a doc comment now; I would suggest:
/// Dynamically round a pointer up
rjmccall added a comment.
Well, this is a really nasty bug.
Please check how this interacts with #pragma pack, which normally takes
precedence over even explicit alignment attributes. If that's the case here,
then what you really want to do is just add the same "ExplicitFieldAlign ||"
clause
rjmccall added a comment.
In http://reviews.llvm.org/D14980#298754, @rsmith wrote:
> GCC's behavior (`aligned` on a field specifies the alignment of the start of
> that field) makes a little more sense to me than Clang's behavior (the type
> and alignment of a field specify a flavour of storage
rjmccall added a comment.
Thank you. A few more style complaints; with those fixed, LGTM.
Comment at: lib/CodeGen/TargetInfo.cpp:166
@@ +165,3 @@
+// Dynamically round a pointer up to a multiple of the given alignment.
+static llvm::Value* emitRoundPointerUpToAlignment(CodeGenF
On Mon, Nov 30, 2015 at 2:31 PM, Richard Smith
wrote:
> On Mon, Nov 30, 2015 at 11:33 AM, John McCall wrote:
>
>> rjmccall added a comment.
>>
>> In http://reviews.llvm.org/D14980#298754, @rsmith wrote:
>>
>> > GCC's behavior (`aligned` on a field specifies the alignment of the
>> start of that
rjmccall added a comment.
I don't mean the actual layout used by Windows targets; I mean the layout used
by the ms_struct pragma / attribute.
Comment at: lib/AST/RecordLayoutBuilder.cpp:1606
@@ -1605,1 +1605,3 @@
+} else if (ExplicitFieldAlign)
+ FieldOffset = llvm::Ro
rjmccall added a comment.
Please feel free to commit after you make this last change.
Comment at: lib/CodeGen/TargetInfo.cpp:216
@@ +215,3 @@
+ }
+ else {
+Addr = Address(Ptr, SlotSize);
LLVM code style is to put the else on the same line as the closing b
rjmccall added inline comments.
Comment at: include/clang/Basic/DiagnosticSemaKinds.td:2790
@@ -2790,1 +2789,3 @@
+ "version 4.4 - the newer offset is used here">,
+ InGroup>;
def warn_transparent_union_attribute_field_size_align : Warning<
No, this diagnostic
rjmccall added inline comments.
Comment at: lib/AST/RecordLayoutBuilder.cpp:1606
@@ -1605,1 +1605,3 @@
+} else if (ExplicitFieldAlign)
+ FieldOffset = llvm::RoundUpToAlignment(FieldOffset, ExplicitFieldAlign);
Be sure to test specifically with an APCS A
rjmccall added a comment.
LGTM, thanks!
http://reviews.llvm.org/D14872
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall added a comment.
Hmm. I think a better approach would be for buildAssignmentOperation to do
this; but before we figure out how to do that, we should make sure of the
language semantics we're implementing. Are the semantics that the result of an
assignment is always the result of the
rjmccall added a comment.
In http://reviews.llvm.org/D15174#302248, @ABataev wrote:
> John,
> the result is always the result of Put operation. For pre-increment we
> have to return new value, for the post-increment - previous value
> returned by Get (checked it on MSVC).
> So, currently po
rjmccall added inline comments.
Comment at: lib/AST/RecordLayoutBuilder.cpp:1606
@@ +1605,3 @@
+} else if (ExplicitFieldAlign &&
+ Context.getTargetInfo().useBitFieldTypeAlignment())
+ FieldOffset = llvm::RoundUpToAlignment(FieldOffset, ExplicitFieldAlign);
rjmccall added inline comments.
Comment at: lib/Sema/SemaPseudoObject.cpp:232
@@ -231,3 +231,3 @@
/// Return true if assignments have a non-void result.
-bool CanCaptureValue(Expr *exp) {
+bool CanCaptureValue(Expr *exp) const {
if (exp->isGLValue())
--
rjmccall added a comment.
Yes, I think that's a reasonable approach.
http://reviews.llvm.org/D14980
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> On Dec 5, 2015, at 7:58 AM, AlexDenisov <1101.deb...@gmail.com> wrote:
> Extend ObjCMigrator to cover automatic migration from message sending to
> boxable literals, e.g.:
>
> ```before
> typedef struct __attribute__((objc_boxable)) CGRect CGRect;
> /// ...
> CGRect rect;
> [NSValue valueWithBy
rjmccall added inline comments.
Comment at: lib/Sema/SemaPseudoObject.cpp:464
@@ -461,1 +463,3 @@
+ if (useSetterResultAsExprResult(result.get()))
+setResultToLastSemantic();
Sure, but that's not what I'm saying. I'm saying that the code, as you've
writte
rjmccall added a comment.
I don't understand why that's true. buildSet is called with
captureSetValueAsResult=true, and the set value is definitely capturable, so
that value should be set as the result; and you're not overriding it. Why does
the expression end up having type void?
http://re
rjmccall added a reviewer: akyrtzi.
Comment at: lib/AST/ASTContext.cpp:5424
@@ -5410,1 +5423,3 @@
+// FIXME: need to figure out what this is for __float128
+case BuiltinType::Float128: return 'K';
case BuiltinType::NullPtr:return '*'; // like char*
-
rjmccall added a comment.
Oh, I see, of course.
It would be clearer if you asked the subclass which value to use abstractly
(i.e. independently of the actual set expression) and then passed down
captureSetValueAsResult=false when the subclass says to use the setter result.
http://reviews.llvm
rjmccall added a comment.
Thanks!
Comment at: lib/Sema/SemaPseudoObject.cpp:249
@@ -248,1 +248,3 @@
+virtual bool useSetterResultAsExprResult(Expr *) const { return false; }
+virtual bool captureSetValueAsResult() const { return true; }
};
I think you
rjmccall added a comment.
Thanks! Just a slight tweak to the comment, then LGTM.
Comment at: lib/Sema/SemaPseudoObject.cpp:259
@@ +258,3 @@
+///
+/// If this method returns false, and the set value isn't capturable for
+/// some reason, the result of the expression
rjmccall added inline comments.
Comment at: lib/Driver/Tools.cpp:1477
@@ +1476,3 @@
+ // If unspecified, choose the default based on the platform.
+ if (ABI == ppc::FloatABI::Invalid) {
+ABI = ppc::FloatABI::Hard;
hfinkel wrote:
> Don't need the { } here.
We
rjmccall added inline comments.
Comment at: lib/Driver/Tools.cpp:1477
@@ +1476,3 @@
+ // If unspecified, choose the default based on the platform.
+ if (ABI == ppc::FloatABI::Invalid) {
+ABI = ppc::FloatABI::Hard;
hfinkel wrote:
> rjmccall wrote:
> > hfinkel
Author: rjmccall
Date: Thu Dec 10 17:31:01 2015
New Revision: 255311
URL: http://llvm.org/viewvc/llvm-project?rev=255311&view=rev
Log:
In Objective-C, ignore attempts to redefine the ARC/GC qualifier macros.
This works around existing system headers which unconditionally
redefine these macros.
T
Author: rjmccall
Date: Thu Dec 10 19:56:36 2015
New Revision: 255325
URL: http://llvm.org/viewvc/llvm-project?rev=255325&view=rev
Log:
Correctly type-check the default arguments of local functions
when eagerly instantiating them.
rdar://23721638
Modified:
cfe/trunk/lib/Sema/SemaTemplateInsta
Author: rjmccall
Date: Mon Dec 14 13:12:54 2015
New Revision: 255531
URL: http://llvm.org/viewvc/llvm-project?rev=255531&view=rev
Log:
Allow pseudo-destructor calls on forward-declared Objective-C class pointers.
rdar://18522255
Added:
cfe/trunk/test/SemaObjCXX/pseudo-destructor.mm
Modified:
rjmccall added a comment.
I'm sorry for the delay. It looks fine, thanks.
http://reviews.llvm.org/D12614
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall added a comment.
Richard should really be the one to sign off on this, since he's been managing
the review so far.
I am curious why we decided to handle this separately instead of treating it as
a different attribute spelling kind.
http://reviews.llvm.org/D10599
__
rjmccall added inline comments.
Comment at: include/clang/Basic/AttrDocs.td:1866
@@ +1865,3 @@
+ let Content = [{
+The attribute ``__attribute__((ifunc("resolver")))`` is used to mark a
function as an indirect function using the STT_GNU_IFUNC symbol type extension
to the ELF st
rjmccall added inline comments.
Comment at: include/clang/Basic/AttrDocs.td:1866
@@ +1865,3 @@
+ let Content = [{
+The attribute ``__attribute__((ifunc("resolver")))`` is used to mark a
function as an indirect function using the STT_GNU_IFUNC symbol type extension
to the ELF st
rjmccall added a comment.
You don't need a CodeGenFunction for this; just use
llvm::ConstantExpr::getBitCast. Please document the requirement that this
returns an i8* in CGObjCRuntime.h.
http://reviews.llvm.org/D15674
___
cfe-commits mailing list
rjmccall added a comment.
Thank you, that's great. LGTM.
http://reviews.llvm.org/D15674
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall added inline comments.
Comment at: include/clang/Basic/Attr.td:255
@@ -254,2 +254,3 @@
def TargetX86 : TargetArch<["x86"]>;
+def TargetIA : TargetArch<["x86", "x86_64"]>;
def TargetWindows : TargetArch<["x86", "x86_64", "arm", "thumb"]> {
As far as I'm
rjmccall added inline comments.
Comment at: tools/clang/lib/AST/ASTContext.cpp:1902
@@ +1901,3 @@
+ if (Target->getTriple().getArch() == llvm::Triple::xcore ||
+ Target->getTriple().isOSIAMCU())
+return ABIAlign; // Never overalign on XCore and IAMCU.
P
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
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
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
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
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
@@ -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:
@@ -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
@@ -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
---
@@ -769,9 +777,10 @@ void CodeGenModule::EmitCXXModuleInitFunc(Module *Primary)
{
CharUnits GuardAlign = CharUnits::One();
Guard->setAlignment(GuardAlign.getAsAlign());
GuardAddr = ConstantAddress(Guard, Int8Ty, GuardAlign);
+ IsTLS = Guard->isThreadLoca
@@ -769,9 +777,10 @@ void CodeGenModule::EmitCXXModuleInitFunc(Module *Primary)
{
CharUnits GuardAlign = CharUnits::One();
Guard->setAlignment(GuardAlign.getAsAlign());
GuardAddr = ConstantAddress(Guard, Int8Ty, GuardAlign);
+ IsTLS = Guard->isThreadLoca
@@ -1070,13 +1084,20 @@
CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn,
// Mark as initialized before initializing anything else. If the
// initializers use previously-initialized thread_local vars, that's
// probably supposed to be OK, but the
@@ -2933,7 +2933,8 @@ void ItaniumCXXABI::EmitThreadLocalInitFuncs(
Guard->setAlignment(GuardAlign.getAsAlign());
CodeGenFunction(CGM).GenerateCXXGlobalInitFunc(
-InitFunc, OrderedInits, ConstantAddress(Guard, CGM.Int8Ty,
GuardAlign));
+InitFunc, Order
https://github.com/rjmccall commented:
This all seems reasonable to me. Please add real documentation for this,
though, not just a release note.
https://github.com/llvm/llvm-project/pull/96944
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
rjmccall wrote:
Yes, I agree that we can reasonably claim to support this for the indefinite
future. This is something we would've seen ourselves as practically
constrained from exploiting anyway, effectively making it well-defined even if
the standard didn't act.
https://github.com/llvm/llv
@@ -1070,13 +1084,20 @@
CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn,
// Mark as initialized before initializing anything else. If the
// initializers use previously-initialized thread_local vars, that's
// probably supposed to be OK, but the
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl = dyn_cast_or_null(Base
@@ -1070,13 +1084,20 @@
CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn,
// Mark as initialized before initializing anything else. If the
// initializers use previously-initialized thread_local vars, that's
// probably supposed to be OK, but the
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/96633
___
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/96633
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1070,13 +1084,20 @@
CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn,
// Mark as initialized before initializing anything else. If the
// initializers use previously-initialized thread_local vars, that's
// probably supposed to be OK, but the
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/96633
___
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/96633
___
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/96633
___
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.
https://github.com/llvm/llvm-project/pull/96944
___
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.
Well, this is wonderful, thank you. LGTM.
https://github.com/llvm/llvm-project/pull/102553
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
rjmccall wrote:
Do you just want whatever the logic is for array subscripts? I believe array
subscripts technically leave the index unconverted, and then we perform the
necessary conversion when emitting IR.
https://github.com/llvm/llvm-project/pull/103044
@@ -4348,8 +4348,18 @@ LValue CodeGenFunction::EmitMatrixSubscriptExpr(const
MatrixSubscriptExpr *E) {
!E->isIncomplete() &&
"incomplete matrix subscript expressions should be rejected during
Sema");
LValue Base = EmitLValue(E->getBase());
- llvm::Value *RowIdx
@@ -4348,8 +4348,18 @@ LValue CodeGenFunction::EmitMatrixSubscriptExpr(const
MatrixSubscriptExpr *E) {
!E->isIncomplete() &&
"incomplete matrix subscript expressions should be rejected during
Sema");
LValue Base = EmitLValue(E->getBase());
- llvm::Value *RowIdx
https://github.com/rjmccall requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/101083
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1121,3 +1121,99 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned
BuiltinID, CallExpr *TheCall) {
}
return false;
}
+
+bool SemaHLSL::CheckCompatibleParameterABI(FunctionDecl *New,
+ FunctionDecl *Old) {
+ if (New->getNumPar
601 - 700 of 1075 matches
Mail list logo
