Re: [clang] 00bc76e - Move Basic{Reader,Writer} emission into ASTPropsEmitter; NFC.

any issues with missing emails lately? On Dec 16, 2019, at 10:34 AM, John McCall via cfe-commits wrote: Author: John McCall Date: 2019-12-16T13:33:59-05:00 New Revision: 00bc76edddb5a6cd417610e96289a5dc15245867 URL: https://github.com/llvm/llvm-project/commit/00bc76edddb5a6cd417610e96289a5dc

Re: [clang] 00bc76e - Move Basic{Reader,Writer} emission into ASTPropsEmitter; NFC.

On 16 Dec 2019, at 15:11, John McCall wrote: On 16 Dec 2019, at 15:07, Vedant Kumar wrote: Hi John, The lldb bot went red after your clang AST changes landed: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/4801/changes#detail0

[clang] 803403a - Fix a bug in the property-based serialization of

Author: John McCall Date: 2019-12-16T16:08:09-05:00 New Revision: 803403afc83f659be1c620eb1896dcf704b18b0a URL: https://github.com/llvm/llvm-project/commit/803403afc83f659be1c620eb1896dcf704b18b0a DIFF: https://github.com/llvm/llvm-project/commit/803403afc83f659be1c620eb1896dcf704b18b0a.diff L

[clang] e4422ae - Rewrite the non-trivial structs section of the ARC spec.

Author: John McCall Date: 2020-03-06T02:51:45-05:00 New Revision: e4422ae0f6e4159a8560514ce221306c30a7f2c1 URL: https://github.com/llvm/llvm-project/commit/e4422ae0f6e4159a8560514ce221306c30a7f2c1 DIFF: https://github.com/llvm/llvm-project/commit/e4422ae0f6e4159a8560514ce221306c30a7f2c1.diff L

[clang] 77b2ffc - Fix a reentrance bug with deserializing ObjC type parameters.

Author: John McCall Date: 2020-02-12T18:44:19-05:00 New Revision: 77b2ffc498e92cce7546d191f6712a3046300501 URL: https://github.com/llvm/llvm-project/commit/77b2ffc498e92cce7546d191f6712a3046300501 DIFF: https://github.com/llvm/llvm-project/commit/77b2ffc498e92cce7546d191f6712a3046300501.diff L

r328942 - Fix a major swiftcall ABI bug with trivial C++ class types.

Author: rjmccall Date: Sun Apr 1 14:04:30 2018 New Revision: 328942 URL: http://llvm.org/viewvc/llvm-project?rev=328942&view=rev Log: Fix a major swiftcall ABI bug with trivial C++ class types. The problem with the previous logic was that there might not be any explicit copy/move constructor dec

Re: r328680 - [ObjC] Make C++ triviality type traits available to non-trivial C

> On Apr 4, 2018, at 7:37 PM, Akira Hatanaka wrote: > > > >> On Apr 4, 2018, at 4:24 PM, Akira Hatanaka via cfe-commits >> mailto:cfe-commits@lists.llvm.org>> wrote: >> >>> >>> On Apr 4, 2018, at 3:38 PM, Richard Smith >> > wrote: >>> >>> Hi Akira, >>> >>> T

Re: r328680 - [ObjC] Make C++ triviality type traits available to non-trivial C

> On Apr 5, 2018, at 3:54 PM, Akira Hatanaka wrote: > > >> On Apr 5, 2018, at 12:39 PM, John McCall > > wrote: >> >> >> >>> On Apr 4, 2018, at 7:37 PM, Akira Hatanaka >> > wrote: >>> >>> >>> On Apr 4, 2018, at 4:24 PM, Akira Hat

r329508 - Allow equality comparisons between block pointers and

Author: rjmccall Date: Sat Apr 7 10:42:06 2018 New Revision: 329508 URL: http://llvm.org/viewvc/llvm-project?rev=329508&view=rev Log: Allow equality comparisons between block pointers and block-pointer-compatible ObjC object pointer types. Patch by Dustin Howett! Added: cfe/trunk/test/SemaO

r329513 - Generalize the swiftcall API since being passed indirectly isn't

Author: rjmccall Date: Sat Apr 7 13:16:47 2018 New Revision: 329513 URL: http://llvm.org/viewvc/llvm-project?rev=329513&view=rev Log: Generalize the swiftcall API since being passed indirectly isn't C++-specific anymore. Modified: cfe/trunk/include/clang/CodeGen/SwiftCallingConv.h cfe/tr

Re: [PATCH] D44883: [Sema] Extend -Wself-assign and -Wself-assign-field to warn on overloaded self-assignment (classes)

If you have a concrete suggestion of how to suppress this warning for user-defined operators just in unit tests, great. I don’t think 8 easily-suppressed warnings is an unacceptably large false-positive problem, though. Most warnings have similar problems, and the standard cannot possibly be “must

Re: [PATCH] D44883: [Sema] Extend -Wself-assign and -Wself-assign-field to warn on overloaded self-assignment (classes)

Yeah, -Wself-assign in general is about catching a class of live-coding errors which is pretty unlikely to ever make it into committed code, since the code would need to be dead/redundant for the mistake to not be noticed. So it’s specifically a rather poor match for the static analyzer, and I woul

Re: [PATCH] D44883: [Sema] Extend -Wself-assign and -Wself-assign-field to warn on overloaded self-assignment (classes)

Also, the standard for the static analyzer is not lower than it is for the compiler. The static analyzer tries to catch a much larger class of bugs, but it also tries very hard to make all the warnings it emits count. There’s a really common problem in the static analysis field where users try a s

Re: [PATCH] D44883: [Sema] Extend -Wself-assign and -Wself-assign-field to warn on overloaded self-assignment (classes)

Do you think they’re bad precedent? Do you have a replacement for that approach to warning about those problems? Because they certainly were precedent for -Wfallthrough, and they certainly catch a class of bugs at least as large and important as that warning, and they certainly have exactly the sam

r317776 - Fix a bug with the use of __builtin_bzero in a conditional expression.

Author: rjmccall Date: Thu Nov 9 01:32:32 2017 New Revision: 317776 URL: http://llvm.org/viewvc/llvm-project?rev=317776&view=rev Log: Fix a bug with the use of __builtin_bzero in a conditional expression. Patch by Bharathi Seshadri! Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp cfe/trun

Re: [PATCH] D9403: llvm.noalias - Clang CodeGen for local restrict-qualified pointers

rjmccall added inline comments. Comment at: lib/CodeGen/CGStmt.cpp:525 @@ +524,3 @@ +void CodeGenFunction::LexicalNoAliasInfo::addNoAliasMD() { + if (MemoryInsts.empty() || NoAliasScopes.empty()) +return; It's much more likely that NoAliasScopes will be empty

Re: [PATCH] D24312: [CodeGen] Fix an assert in EmitNullConstant

rjmccall added a comment. LGTM. https://reviews.llvm.org/D24312 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D21104: [CodeGen][ObjC] Block captures should inherit the type of the captured field in the enclosing lambda or block

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. LGTM. https://reviews.llvm.org/D21104 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/

Re: [PATCH] D24461: CodeGen: Cast llvm.flt.rounds result to match __builtin_flt_rounds

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. LGTM. https://reviews.llvm.org/D24461 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/

r281693 - Alter the iOS/tvOS ARM64 C++ ABI to ignore the upper half of the

Author: rjmccall Date: Thu Sep 15 21:40:45 2016 New Revision: 281693 URL: http://llvm.org/viewvc/llvm-project?rev=281693&view=rev Log: Alter the iOS/tvOS ARM64 C++ ABI to ignore the upper half of the virtual table offset in a member function pointer. We are reserving this space for future ABI use

r307760 - Expose some type-conversion functions as part of the IRGen ABI.

Author: rjmccall Date: Wed Jul 12 00:44:17 2017 New Revision: 307760 URL: http://llvm.org/viewvc/llvm-project?rev=307760&view=rev Log: Expose some type-conversion functions as part of the IRGen ABI. Patch by Benoit Vey! Modified: cfe/trunk/include/clang/CodeGen/CodeGenABITypes.h cfe/trun

r308092 - Use ARC parsing rules for ns_returns_retained in MRC so that code can

Author: rjmccall Date: Sat Jul 15 04:06:46 2017 New Revision: 308092 URL: http://llvm.org/viewvc/llvm-project?rev=308092&view=rev Log: Use ARC parsing rules for ns_returns_retained in MRC so that code can be shared without warnings. Build AttributedTypes to leave breadcrumbs for tools like the st

r322406 - Allocate and access NormalCleanupDest with the natural alignment of i32.

Author: rjmccall Date: Fri Jan 12 14:07:01 2018 New Revision: 322406 URL: http://llvm.org/viewvc/llvm-project?rev=322406&view=rev Log: Allocate and access NormalCleanupDest with the natural alignment of i32. This alignment can be less than 4 on certain embedded targets, which may not even be able

r296806 - Promote ConstantInitBuilder to be a public CodeGen API; it's

Author: rjmccall Date: Thu Mar 2 14:04:19 2017 New Revision: 296806 URL: http://llvm.org/viewvc/llvm-project?rev=296806&view=rev Log: Promote ConstantInitBuilder to be a public CodeGen API; it's a generally useful utility for other frontends. NFC. Added: cfe/trunk/include/clang/CodeGen/Cons

r296979 - Refactor ConstantInitBuilder to allow other frontends to more

Author: rjmccall Date: Sat Mar 4 15:26:29 2017 New Revision: 296979 URL: http://llvm.org/viewvc/llvm-project?rev=296979&view=rev Log: Refactor ConstantInitBuilder to allow other frontends to more easily extend the aggregate-builder API. Stupid missing language features. Also add APIs for constr

r296980 - GCC workaround: use explicit qualification to avoid injected class name.

Author: rjmccall Date: Sat Mar 4 15:46:14 2017 New Revision: 296980 URL: http://llvm.org/viewvc/llvm-project?rev=296980&view=rev Log: GCC workaround: use explicit qualification to avoid injected class name. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 Modified: cfe/trunk/include/clang

r297050 - Further fixes and improvements to the ConstantInitBuilder API.

Author: rjmccall Date: Mon Mar 6 13:04:16 2017 New Revision: 297050 URL: http://llvm.org/viewvc/llvm-project?rev=297050&view=rev Log: Further fixes and improvements to the ConstantInitBuilder API. Added: cfe/trunk/include/clang/CodeGen/ConstantInitFuture.h Modified: cfe/trunk/include/cla

r287291 - Forward ns_consumed delegate arguments with a move.

Author: rjmccall Date: Thu Nov 17 19:08:24 2016 New Revision: 287291 URL: http://llvm.org/viewvc/llvm-project?rev=287291&view=rev Log: Forward ns_consumed delegate arguments with a move. StartFunction enters a release cleanup for ns_consumed arguments in ARC, so we need to balance that somehow.

r287437 - Introduce a helper class for building complex constant initializers. NFC.

Author: rjmccall Date: Sat Nov 19 02:17:24 2016 New Revision: 287437 URL: http://llvm.org/viewvc/llvm-project?rev=287437&view=rev Log: Introduce a helper class for building complex constant initializers. NFC. I've adopted this in most of the places it makes sense, but v-tables and CGObjCMac will

r287458 - Remove alignment from ctors/dtors lists in an attempt to placate LTO.

Author: rjmccall Date: Sat Nov 19 14:12:25 2016 New Revision: 287458 URL: http://llvm.org/viewvc/llvm-project?rev=287458&view=rev Log: Remove alignment from ctors/dtors lists in an attempt to placate LTO. Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp Modified: cfe/trunk/lib/CodeGen/CodeG

[PATCH] D26196: Add support for non-zero null pointer for C and OpenCL

rjmccall added a comment. In https://reviews.llvm.org/D26196#602660, @yaxunl wrote: > > But if you do need to support these conversions for some reason, the > > correct behavior is to ensure that null is mapped to null. > > I only need to do this for constant folding, right? I found that the cur

r287691 - Remove variable only used in an assertion.

Author: rjmccall Date: Tue Nov 22 14:12:32 2016 New Revision: 287691 URL: http://llvm.org/viewvc/llvm-project?rev=287691&view=rev Log: Remove variable only used in an assertion. Modified: cfe/trunk/lib/CodeGen/CGBlocks.cpp Modified: cfe/trunk/lib/CodeGen/CGBlocks.cpp URL: http://llvm.org/vi

[PATCH] D26978: [Sema][Atomics] Treat expected pointer in compare exchange atomics as _Nonnull

rjmccall added a comment. LGTM. Repository: rL LLVM https://reviews.llvm.org/D26978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r288081 - Make CGVTables use ConstantInitBuilder. NFC.

Author: rjmccall Date: Mon Nov 28 16:18:33 2016 New Revision: 288081 URL: http://llvm.org/viewvc/llvm-project?rev=288081&view=rev Log: Make CGVTables use ConstantInitBuilder. NFC. Modified: cfe/trunk/lib/CodeGen/CGVTables.cpp cfe/trunk/lib/CodeGen/CGVTables.h cfe/trunk/lib/CodeGen/It

r288080 - Hide the result of building a constant initializer. NFC.

Author: rjmccall Date: Mon Nov 28 16:18:30 2016 New Revision: 288080 URL: http://llvm.org/viewvc/llvm-project?rev=288080&view=rev Log: Hide the result of building a constant initializer. NFC. Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp cfe/

r288079 - ConstantBuilder -> ConstantInitBuilder for clarity, and

Author: rjmccall Date: Mon Nov 28 16:18:27 2016 New Revision: 288079 URL: http://llvm.org/viewvc/llvm-project?rev=288079&view=rev Log: ConstantBuilder -> ConstantInitBuilder for clarity, and move the member classes up to top level to allow forward declarations to name them. NFC. Modified: cf

Re: [PATCH] D27163: Introduce -f[no-]strict-return flag that controls code generation for C++'s undefined behaviour return optimisation

On Mon, Nov 28, 2016 at 2:48 PM, Richard Smith wrote: > (Dropping Phabricator, since this isn't really about D27163...) > > On 28 November 2016 at 14:27, John McCall via Phabricator via cfe-commits > wrote: > >> In https://reviews.llvm.org/D27163#607100, @rsmith wrote: >> > C has rather differen

r288203 - getObjCEncodingForMethodDecl cannot fail. Simplify. NFC.

Author: rjmccall Date: Tue Nov 29 15:57:00 2016 New Revision: 288203 URL: http://llvm.org/viewvc/llvm-project?rev=288203&view=rev Log: getObjCEncodingForMethodDecl cannot fail. Simplify. NFC. Modified: cfe/trunk/include/clang/AST/ASTContext.h cfe/trunk/lib/AST/ASTContext.cpp cfe/tru

r288231 - Prospective GCC build fix: the unelaborated form of this friend

Author: rjmccall Date: Tue Nov 29 22:18:19 2016 New Revision: 288231 URL: http://llvm.org/viewvc/llvm-project?rev=288231&view=rev Log: Prospective GCC build fix: the unelaborated form of this friend declaration should find the right type, assuming it's supported evenly across all our hosts. Modif

r288269 - Finish adopting ConstantInitBuilder in CGObjCGNU. NFC.

Author: rjmccall Date: Wed Nov 30 14:19:46 2016 New Revision: 288269 URL: http://llvm.org/viewvc/llvm-project?rev=288269&view=rev Log: Finish adopting ConstantInitBuilder in CGObjCGNU. NFC. Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp cfe/trunk/lib/CodeGen/ConstantBuilder.h Modified: c

r288272 - Prospective MSVC workaround.

Author: rjmccall Date: Wed Nov 30 14:46:55 2016 New Revision: 288272 URL: http://llvm.org/viewvc/llvm-project?rev=288272&view=rev Log: Prospective MSVC workaround. Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp URL: http://llvm.org/viewvc/llvm-pr

r288287 - Fix some layering violations where CGObjCMac's NSString emission was

Author: rjmccall Date: Wed Nov 30 17:15:55 2016 New Revision: 288287 URL: http://llvm.org/viewvc/llvm-project?rev=288287&view=rev Log: Fix some layering violations where CGObjCMac's NSString emission was performed at the CodeGenModule level. Would be NFC except we now also use a different uniquin

r288289 - Introduce a type-safe enum for ForDefinition.

Author: rjmccall Date: Wed Nov 30 17:25:13 2016 New Revision: 288289 URL: http://llvm.org/viewvc/llvm-project?rev=288289&view=rev Log: Introduce a type-safe enum for ForDefinition. Modified: cfe/trunk/lib/CodeGen/CGCXX.cpp cfe/trunk/lib/CodeGen/CodeGenModule.cpp cfe/trunk/lib/CodeGen/

r288295 - Clean up CGObjCMac's APIs for deriving class references. NFC.

Author: rjmccall Date: Wed Nov 30 17:54:50 2016 New Revision: 288295 URL: http://llvm.org/viewvc/llvm-project?rev=288295&view=rev Log: Clean up CGObjCMac's APIs for deriving class references. NFC. Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp cfe/trunk/lib/CodeGen/CGObjCMac.cpp cfe/t

Re: r288269 - Finish adopting ConstantInitBuilder in CGObjCGNU. NFC.

-and-enumerators-properly> > > I only mention it because you're modifying code that was clearly in the > leading uppercase camp to leading lower case, so you weren't fitting into an > existing style common to some local source file. > > On Wed, Nov 30, 2016 at 12:1

r288313 - Teach ConstantBuilder how to emit a reference to the current position

Author: rjmccall Date: Wed Nov 30 23:33:30 2016 New Revision: 288313 URL: http://llvm.org/viewvc/llvm-project?rev=288313&view=rev Log: Teach ConstantBuilder how to emit a reference to the current position that will be filled in when the initializer is set. Modified: cfe/trunk/lib/CodeGen/Cons

r288440 - Struct GEPs must use i32, not whatever size_t is. It should be safe

Author: rjmccall Date: Thu Dec 1 17:51:30 2016 New Revision: 288440 URL: http://llvm.org/viewvc/llvm-project?rev=288440&view=rev Log: Struct GEPs must use i32, not whatever size_t is. It should be safe to do this unconditionally, given that the indices will always be small constant integers anyw

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin wrote: > So you believe that you can index into an object randomly by pointer >>> arithmetic and pull out a different field? >>> >> >> For starters, this is illegal because you don't know where the padding >> bytes are. >> You cannot assume that X.a

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

On Mon, May 1, 2017 at 6:40 PM, Daniel Berlin wrote: > On Mon, May 1, 2017 at 3:09 PM, Daniel Berlin wrote: > >> On Mon, May 1, 2017 at 2:07 PM, John McCall wrote: >> >>> On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin >>> wrote: >>> So you believe that you can index into an object randomly

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

On Mon, May 1, 2017 at 7:06 PM, Daniel Berlin wrote: > On Mon, May 1, 2017 at 3:58 PM, John McCall wrote: > >> On Mon, May 1, 2017 at 6:40 PM, Daniel Berlin >> wrote: >> >>> On Mon, May 1, 2017 at 3:09 PM, Daniel Berlin >>> wrote: >>> On Mon, May 1, 2017 at 2:07 PM, John McCall wrote: >>

[PATCH] D25448: [ubsan] Disable -fsanitize=vptr checks for devirtualized calls

rjmccall added a comment. In https://reviews.llvm.org/D25448#571941, @vsk wrote: > Thanks for your feedback so far, and sorry for the delayed response. > > In https://reviews.llvm.org/D25448#570014, @rjmccall wrote: > > > Wait, can you talk me through the bug here? > > > Derived inherits from Bas

[PATCH] D25547: [CodeGen][ObjC] Do not emit objc_storeStrong to initialize a constexpr variable

rjmccall added a comment. Thanks! A couple minor tweaks, then LGTM. Comment at: lib/CodeGen/CGExpr.cpp:1652 +Src = RValue::get(EmitObjCExtendObjectLifetime(Dst.getType(), + Src.getScalarVal())); // fall into

[PATCH] D25556: [Sema] Add variable captured by a block to the enclosing lambda's potential capture list

rjmccall added a comment. In https://reviews.llvm.org/D25556#572054, @ahatanak wrote: > In https://reviews.llvm.org/D25556#569809, @rjmccall wrote: > > > Richard should probably weigh in about whether we should be recording > > potential captures at *all* capturing scopes. But at the very least

[PATCH] D25448: [ubsan] Use the object pointer's type info for devirtualized calls

rjmccall added a comment. In https://reviews.llvm.org/D25448#572245, @vsk wrote: > Patch update: Pass along the type info of the derived class to the ubsan > runtime when we devirtualize a method call. This squashes the FP. I tested > this with 'check-ubsan' in addition to adding a lit test. >

[PATCH] D25448: [ubsan] Use the object pointer's type info for devirtualized calls

rjmccall added inline comments. Comment at: lib/CodeGen/CGExprCXX.cpp:31 +CallArgList &Args, CallArgList *RtlArgs, +llvm::Optional DevirtualizedClassTy) { assert(CE == nullptr || isa(CE) || Shouldn't MD just be the devirtualized method? That should av

[PATCH] D25547: [CodeGen][ObjC] Do not emit objc_storeStrong to initialize a constexpr variable

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. Thanks, that looks great! LGTM. https://reviews.llvm.org/D25547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.or

[PATCH] D25448: [ubsan] Use the object pointer's type info for devirtualized calls

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. Looks great, thanks. https://reviews.llvm.org/D25448 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/ma

[PATCH] D25777: [Sema][TreeTransform] Re-create DesignatedInitExpr when it has a field designator with a valid FieldDecl

rjmccall added a comment. The fact that this bug only arises when performing a *second* instantiation suggests that there's a deeper bug here, because template instantiation is not supposed to modify the pattern AST. In this case, the basic problem is that, when the parser processes a designat

[PATCH] D25813: [CodeGen] Devirtualize calls to methods marked final in a derived class

rjmccall added a comment. Looks great to me, thanks. https://reviews.llvm.org/D25813 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25844: [Sema][ObjC] Warn about implicitly autoreleasing indirect parameters that are captured by blocks

rjmccall added inline comments. Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5080 +def note_explicit_ownership_qualification : Note< + "explicitly specify ownership qualification">; + How about: warning: block captures an autoreleasing out-parameter,

[PATCH] D25844: [Sema][ObjC] Warn about implicitly autoreleasing indirect parameters that are captured by blocks

rjmccall added a comment. Thanks. LGTM. https://reviews.llvm.org/D25844 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25777: [Sema][TreeTransform] Re-create DesignatedInitExpr when it has a field designator with a valid FieldDecl

rjmccall added a comment. Thanks, LGTM with a small tweak. Comment at: lib/Sema/TreeTransform.h:8928 +FieldDecl *Field = dyn_cast_or_null( +getDerived().TransformDecl(D.getFieldLoc(), D.getField())); +if (Field != D.getField()) I'm p

[PATCH] D25937: [Sema] -Wunused-variable warning for variables with array types should behave similarly to variables with scalar types

rjmccall requested changes to this revision. rjmccall added a comment. This revision now requires changes to proceed. There's no reason for this to only consider constant-sized arrays, and you should use getBaseElementTypeUnsafe() so you look through nested array types. That method is a no-op o

[PATCH] D25937: [Sema] -Wunused-variable warning for variables with array types should behave similarly to variables with scalar types

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. Please add a line testing the nested-array case to warn-unused-variables.cpp, but with that, LGTM. Repository: rL LLVM https://reviews.llvm.org/D25937 __

r285258 - Refactor call emission to package the function pointer together with

Author: rjmccall Date: Wed Oct 26 18:46:34 2016 New Revision: 285258 URL: http://llvm.org/viewvc/llvm-project?rev=285258&view=rev Log: Refactor call emission to package the function pointer together with abstract information about the callee. NFC. The goal here is to make it easier to recognize

r285643 - A compound literal within a global lambda or block is still within

Author: rjmccall Date: Mon Oct 31 16:56:26 2016 New Revision: 285643 URL: http://llvm.org/viewvc/llvm-project?rev=285643&view=rev Log: A compound literal within a global lambda or block is still within the body of a function for the purposes of computing its storage duration and deciding whether i

[PATCH] D26189: Add a note that points to the linkage specifier for the "must have C++ linkage" errors

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. LGTM. Repository: rL LLVM https://reviews.llvm.org/D26189 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cg

[PATCH] D26196: AMDGPU: Translate null pointers in private and local addr space

rjmccall added a comment. I think there are a number of conceptual questions here, chiefly among them whether an llvm::ConstantPointerNull in an address-space type should have the correct representation for the target. If the decision for that is "no", then ok, we can produce an explicit repre

[PATCH] D26196: AMDGPU: Translate null pointers in private and local addr space

rjmccall added a comment. In https://reviews.llvm.org/D26196#587135, @yaxunl wrote: > In https://reviews.llvm.org/D26196#586433, @rjmccall wrote: > > > I think there are a number of conceptual questions here, chiefly among them > > whether an llvm::ConstantPointerNull in an address-space type sh

r286152 - Name some anonymous structs to avoid using a (very common) extension.

Author: rjmccall Date: Mon Nov 7 15:13:27 2016 New Revision: 286152 URL: http://llvm.org/viewvc/llvm-project?rev=286152&view=rev Log: Name some anonymous structs to avoid using a (very common) extension. Modified: cfe/trunk/lib/CodeGen/CGCall.h Modified: cfe/trunk/lib/CodeGen/CGCall.h URL:

Re: r285258 - Refactor call emission to package the function pointer together with

struct { > ^ > /llvm/tools/zapccs/../clang/include/../lib/CodeGen/CGCall.h:83:7: warning: > anonymous types declared in an anonymous union are an extension > [-Wnested-anon-types] > struct { > ^ > Thanks. Should be fixed in r286152. John. > > &

[PATCH] D26196: [WIP] Add support for non-zero null pointers

rjmccall added inline comments. Comment at: lib/CodeGen/CGExprConstant.cpp:1340 + return C; +return getNullPtr(PT, DestType); } efriedma wrote: > Consider code like the following: > > int x = 0; > auto y1 = (__specialaddrspace int

[PATCH] D25764: Add end location of loop to loop metadata.

rjmccall added a comment. In https://reviews.llvm.org/D25764#588752, @hfinkel wrote: > This makes sense to me; @anemet , @rjmccall , any thoughts? Why are the constructor arguments optional? Are there actually any loops that we push that lack start and end locs? https://reviews.llvm.org/D2

[PATCH] D26196: Add support for non-zero null pointers

rjmccall added inline comments. Comment at: lib/CodeGen/CGExprConstant.cpp:1340 + return C; +return getNullPtr(PT, DestType); } yaxunl wrote: > efriedma wrote: > > yaxunl wrote: > > > yaxunl wrote: > > > > rjmccall wrote: > > > > > efriedm

[PATCH] D26196: Add support for non-zero null pointers

rjmccall added a comment. In https://reviews.llvm.org/D26196#589493, @yaxunl wrote: > Fixed list initialization of large struct which are mostly initialized by 0 > through memset. > Added tests for casting literal 0 and non-literal integer to pointer. > > There are many more places need to be c

[PATCH] D25764: Add end location of loop to loop metadata.

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. Looks good, thanks! https://reviews.llvm.org/D25764 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mai

[PATCH] D26196: Add support for non-zero null pointers

rjmccall added inline comments. Comment at: lib/CodeGen/TargetInfo.cpp:7040 + auto AS = PT->getAddressSpace(); + return AS != Ctx.getTargetAddressSpace(LangAS::opencl_local) && AS != 0; +} yaxunl wrote: > rjmccall wrote: > > This check is definitely not correct;

[PATCH] D26410: [CodeGen] Don't emit the same global block multiple times.

rjmccall added a comment. This looks great. One minor tweak and then it's ready. Comment at: lib/CodeGen/CGBlocks.cpp:1057 +void CodeGenModule::putAddrOfGlobalBlock(const BlockExpr *BE, + llvm::Constant *Addr) { + bool Ok = EmittedGloba

[PATCH] D26196: Add support for non-zero null pointer for C and OpenCL

rjmccall added a comment. In https://reviews.llvm.org/D26196#592823, @yaxunl wrote: > Hi John, > > It seems the casting from a pointer to different address space is not > affected by this change. When a null pointer is casted to different address > space, it is casted the same way as an ordinar

[PATCH] D26196: Add support for non-zero null pointer for C and OpenCL

rjmccall added a comment. In https://reviews.llvm.org/D26196#593741, @yaxunl wrote: > >> It seems the casting from a pointer to different address space is not > >> affected by this change. When a null pointer is casted to different > >> address space, it is casted the same way as an ordinary po

r246991 - When building the alloca for a local variable, set its name

Author: rjmccall Date: Tue Sep 8 04:18:30 2015 New Revision: 246991 URL: http://llvm.org/viewvc/llvm-project?rev=246991&view=rev Log: When building the alloca for a local variable, set its name separately from building the instruction so that it's preserved even in -Asserts builds. Employ C++'s

r246993 - Another fix to this test, this one apparently working by

Author: rjmccall Date: Tue Sep 8 04:33:33 2015 New Revision: 246993 URL: http://llvm.org/viewvc/llvm-project?rev=246993&view=rev Log: Another fix to this test, this one apparently working by coincidence on all bots. Modified: cfe/trunk/test/CodeGenCXX/alignment.cpp Modified: cfe/trunk/test/

Re: r246991 - When building the alloca for a local variable, set its name

> On Sep 8, 2015, at 8:25 AM, David Blaikie wrote: > On Tue, Sep 8, 2015 at 2:18 AM, John McCall via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > Author: rjmccall > Date: Tue Sep 8 04:18:30 2015 > New Revision: 246991 > > URL: http://llvm.org/viewv

Re: r246991 - When building the alloca for a local variable, set its name

> On Sep 8, 2015, at 10:52 AM, Chandler Carruth wrote: > None of my performance concerns were relevant to this change FWIW. > > I think the reason that this got "fixed" was because people had a tendancy to > *rely* on the name downstream when we made it always present. =/ Personally, > I like h

r247075 - Collect SEH captures in a set instead of a vector to avoid

Author: rjmccall Date: Tue Sep 8 16:15:22 2015 New Revision: 247075 URL: http://llvm.org/viewvc/llvm-project?rev=247075&view=rev Log: Collect SEH captures in a set instead of a vector to avoid doing redundant work if a variable is used multiple times. Fixes PR24751. Modified: cfe/trunk/lib/

Re: r246985 - Compute and preserve alignment more faithfully in IR-generation.

> On Sep 8, 2015, at 6:19 PM, Steven Wu wrote: > CreateElementBitcast doesn’t seem to do what the name suggested. If you give > it VTy, it doesn’t grab the element type to generate bitcast. Is this > by-design? If so, I need to do this: > PtrOp0 = Builder.CreateElementBitCast(PtrOp0, VTy->getEle

r247207 - Fix access control for lookups using the Microsoft __super extension.

Author: rjmccall Date: Wed Sep 9 18:04:17 2015 New Revision: 247207 URL: http://llvm.org/viewvc/llvm-project?rev=247207&view=rev Log: Fix access control for lookups using the Microsoft __super extension. rdar://22464808 Added: cfe/trunk/test/SemaCXX/microsoft-super.cpp Modified: cfe/tru

r247209 - ARC: Fix the precise-lifetime suppression of returns_inner_pointer

Author: rjmccall Date: Wed Sep 9 18:37:17 2015 New Revision: 247209 URL: http://llvm.org/viewvc/llvm-project?rev=247209&view=rev Log: ARC: Fix the precise-lifetime suppression of returns_inner_pointer receiver extension for message sends via property syntax. rdar://22172983 Modified: cfe/tr

r247228 - Don't crash when emitting a block under returns_nonnull.

Author: rjmccall Date: Wed Sep 9 19:57:46 2015 New Revision: 247228 URL: http://llvm.org/viewvc/llvm-project?rev=247228&view=rev Log: Don't crash when emitting a block under returns_nonnull. rdar://22071955 Added: cfe/trunk/test/CodeGen/sanitize-blocks.c Modified: cfe/trunk/lib/CodeGen/

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

rjmccall added inline comments. Comment at: lib/CodeGen/CGException.cpp:276 @@ +275,3 @@ +llvm::Function *F = dyn_cast(U); +if (!U) return false; + if (!F) You should test this by adding an uncommon use of the personality function. Just declare it as a

r247350 - Support noreturn in limited contexts on Objective-C message sends.

Author: rjmccall Date: Thu Sep 10 17:27:50 2015 New Revision: 247350 URL: http://llvm.org/viewvc/llvm-project?rev=247350&view=rev Log: Support noreturn in limited contexts on Objective-C message sends. rdar://6198039 Added: cfe/trunk/test/CodeGenObjC/attr-noreturn.m Modified: cfe/trunk/l

Re: [PATCH] D1623: Support __builtin_ms_va_list.

rjmccall added a comment. This is a kindof weird extension conceptually. "Emulate the C ABI that Microsoft would use on the current architecture"? I guess we're lucky that they never support two different C ABIs on the same ISA. But okay, whatever, it's a thing. A couple comments: ===

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

rjmccall added a comment. LGTM, thanks. http://reviews.llvm.org/D12743 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11361: [OpenMP] Target directive host codegen

rjmccall added a comment. Sorry for putting off the final review on this; I was heads-down trying to get the alignment patch done. It's looking good; obviously you'll need to update it to work with Addresses properly, but hopefully that won't be too much of a problem. When you do, maybe you s

Re: [PATCH] D12312: Emiting invariant.group.barrier and adding -fstrict-vptrs

rjmccall added a comment. LGTM. Comment at: lib/CodeGen/CGClass.cpp:1234 @@ -1233,1 +1233,3 @@ +static bool isInitilierOfDynamicClass(const CXXCtorInitializer *BaseInit) { + const Type *BaseType = BaseInit->getBaseClass(); "Initializer" But I think you can j

Re: [PATCH] D12743: [CodeGen] Teach SimplifyPersonality about the updated LandingPadInst

rjmccall added a comment. In http://reviews.llvm.org/D12743#244375, @vsk wrote: > Ah, ok. We have some objective-c++ code which calls into a boost routine > which throws an exception. That results in an undefined reference to > ___objc_personality_v0, because the boost library we linked against

r247482 - When comparing two block captures for layout, don't crash

Author: rjmccall Date: Fri Sep 11 17:00:51 2015 New Revision: 247482 URL: http://llvm.org/viewvc/llvm-project?rev=247482&view=rev Log: When comparing two block captures for layout, don't crash if they have the same alignment and one was 'this'. Fixes PR24780. Modified: cfe/trunk/lib/CodeGen/

r247597 - Fix a nasty bug with the partial destruction of nested arrays;

Author: rjmccall Date: Mon Sep 14 13:57:08 2015 New Revision: 247597 URL: http://llvm.org/viewvc/llvm-project?rev=247597&view=rev Log: Fix a nasty bug with the partial destruction of nested arrays; it escaped notice because it's only used for heterogeneous initialization. rdar://21397946 Modifie

Re: [PATCH] D12793: Three new security overflow builtins with generic argument types

rjmccall added a comment. Thanks for doing this; this is a great start. Comment at: docs/LanguageExtensions.rst:1720 @@ -1712,1 +1719,3 @@ +being stored there, and the function returns 1. The behavior of these builtins +is well-defined for all argument values. ---

Re: [PATCH] D12793: Three new security overflow builtins with generic argument types

rjmccall added inline comments. Comment at: docs/LanguageExtensions.rst:1720 @@ -1712,1 +1719,3 @@ +being stored there, and the function returns 1. The behavior of these builtins +is well-defined for all argument values. DavidEGrayson wrote: > rjmccall wrote: >

<    1   2   3   4   5   6   7   8   9   10   >