r341489 - Add -Wobjc-property-assign-on-object-type.

Author: rjmccall Date: Wed Sep 5 12:02:00 2018 New Revision: 341489 URL: http://llvm.org/viewvc/llvm-project?rev=341489&view=rev Log: Add -Wobjc-property-assign-on-object-type. This is a warning about using 'assign' instead of 'unsafe_unretained' in Objective-C property declarations. It's off b

r341491 - Forbid address spaces on compound literals in local scope.

Author: rjmccall Date: Wed Sep 5 12:22:40 2018 New Revision: 341491 URL: http://llvm.org/viewvc/llvm-project?rev=341491&view=rev Log: Forbid address spaces on compound literals in local scope. Patch by Bevin Hansson! Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td cfe/tru

r337525 - Document -fobjc-weak as an extension.

Author: rjmccall Date: Thu Jul 19 22:40:12 2018 New Revision: 337525 URL: http://llvm.org/viewvc/llvm-project?rev=337525&view=rev Log: Document -fobjc-weak as an extension. Fixes rdar://24091053. Modified: cfe/trunk/docs/LanguageExtensions.rst Modified: cfe/trunk/docs/LanguageExtensions.rst

r337524 - Fix and improve the ARC spec's wording about unmanaged objects.

Author: rjmccall Date: Thu Jul 19 22:40:09 2018 New Revision: 337524 URL: http://llvm.org/viewvc/llvm-project?rev=337524&view=rev Log: Fix and improve the ARC spec's wording about unmanaged objects. Modified: cfe/trunk/docs/AutomaticReferenceCounting.rst Modified: cfe/trunk/docs/AutomaticRef

r324377 - Pass around function pointers as CGCallees, not bare llvm::Value*s.

Author: rjmccall Date: Tue Feb 6 10:52:44 2018 New Revision: 324377 URL: http://llvm.org/viewvc/llvm-project?rev=324377&view=rev Log: Pass around function pointers as CGCallees, not bare llvm::Value*s. The intention here is to make it easy to write frontend-assisted CFI systems by propagating ex

r304951 - When determining the target function of an explicit instantiation, make

Author: rjmccall Date: Wed Jun 7 18:00:05 2017 New Revision: 304951 URL: http://llvm.org/viewvc/llvm-project?rev=304951&view=rev Log: When determining the target function of an explicit instantiation, make sure that non-template functions don't end up in the candidate set. Fixes PR14211. Patch

Re: [PATCH] D17143: [Sema] PR25156 Crash when parsing dtor call on incomplete type

On Sun, Jun 11, 2017 at 9:26 AM, don hinton wrote: > On Sat, Jun 10, 2017 at 8:55 PM John McCall via Phabricator < > revi...@reviews.llvm.org> wrote: > >> rjmccall accepted this revision. >> rjmccall added a comment. >> This revision is now accepted and ready to land. >> >> Thanks, looks great. >

r305169 - Don't crash when forming a destructor name on an incomplete type.

Author: rjmccall Date: Sun Jun 11 15:33:00 2017 New Revision: 305169 URL: http://llvm.org/viewvc/llvm-project?rev=305169&view=rev Log: Don't crash when forming a destructor name on an incomplete type. Fixes PR25156. Patch by Don Hinton! Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp cfe/t

r320721 - In an ARC lambda-to-block conversion thunk, reclaim the return value of

Author: rjmccall Date: Thu Dec 14 10:21:14 2017 New Revision: 320721 URL: http://llvm.org/viewvc/llvm-project?rev=320721&view=rev Log: In an ARC lambda-to-block conversion thunk, reclaim the return value of the lambda so that we don't over-release it. Patch by Dan Zimmerman! Added: cfe/trunk

trivial_abi

Hey, Richard et al. Akira and I were talking about the right ABI rule for deciding can-pass-in-registers-ness for structs in the presence of trivial_abi, and I think I like Akira's approach but wanted to get your input. The current definition in Itanium is: non-trivial for the purposes of ca

Re: trivial_abi

> On Jan 2, 2018, at 9:15 PM, Akira Hatanaka wrote: > > > >> On Jan 2, 2018, at 4:56 PM, Richard Smith via cfe-commits >> mailto:cfe-commits@lists.llvm.org>> wrote: >> >> On 2 January 2018 at 15:33, John McCall via cfe-commits >> mailto:cfe

Re: trivial_abi

> On Jan 2, 2018, at 10:43 PM, Richard Smith wrote: > > On 2 January 2018 at 19:02, John McCall via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > >> On Jan 2, 2018, at 9:15 PM, Akira Hatanaka > <mailto:ahatan...@apple.com>> wrote: >

Re: [PATCH] D41039: Add support for attribute "trivial_abi"

On Wed, Jan 3, 2018 at 12:24 PM, Akira Hatanaka wrote: > On Jan 2, 2018, at 9:42 AM, David Blaikie via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > > > > On Tue, Dec 19, 2017 at 9:43 PM Akira Hatanaka wrote: > >> On Tue, Dec 12, 2017 at 12:12 PM, John McCall wrote: >> >>> On Tue, Dec 12

Re: trivial_abi

> On Jan 3, 2018, at 5:12 PM, Richard Smith wrote: > > On 2 January 2018 at 20:55, John McCall via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: >> On Jan 2, 2018, at 10:43 PM, Richard Smith > <mailto:rich...@metafoo.co.uk>> wrote: >> >

Re: trivial_abi

> On Jan 3, 2018, at 5:53 PM, Richard Smith wrote: > On 3 January 2018 at 14:29, John McCall via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > >> On Jan 3, 2018, at 5:12 PM, Richard Smith > <mailto:rich...@metafoo.co.uk>> wrote: >> >

Re: [PATCH] D41039: Add support for attribute "trivial_abi"

On Wed, Jan 3, 2018 at 2:07 PM, Akira Hatanaka wrote: > On Jan 3, 2018, at 10:25 AM, John McCall wrote: > > On Wed, Jan 3, 2018 at 12:24 PM, Akira Hatanaka > wrote: > >> On Jan 2, 2018, at 9:42 AM, David Blaikie via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >> >> >> On Tue, Dec 19,

r321957 - Simplify the internal API for checking whether swiftcall passes a type indirectly and expose that API externally.

Author: rjmccall Date: Sat Jan 6 22:28:49 2018 New Revision: 321957 URL: http://llvm.org/viewvc/llvm-project?rev=321957&view=rev Log: Simplify the internal API for checking whether swiftcall passes a type indirectly and expose that API externally. Modified: cfe/trunk/include/clang/CodeGen/S

Re: trivial_abi

Jan 3, 2018 at 4:06 PM Richard Smith via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > On 3 January 2018 at 15:24, John McCall via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: >> On Jan 3, 2018, at 5:53 PM, Richard Smith > <mailto:rich...@metafoo.co

Re: r326946 - CodeGen: Fix address space of indirect function argument

> On Mar 9, 2018, at 8:51 PM, Richard Smith wrote: > > Hi, > > This change increases the size of a CallArg, and thus that of a CallArgList, > dramatically (an LValue is *much* larger than an RValue, and unlike an > RValue, does not appear to be at all optimized for size). This results in > Ca

r333791 - Cap "voluntary" vector alignment at 16 for all Darwin platforms.

Author: rjmccall Date: Fri Jun 1 14:34:26 2018 New Revision: 333791 URL: http://llvm.org/viewvc/llvm-project?rev=333791&view=rev Log: Cap "voluntary" vector alignment at 16 for all Darwin platforms. This fixes two major problems: - We were not capping vector alignment as desired on 32-bit ARM. -

r345536 - In swiftcall, don't merge FP/vector types within a chunk.

Author: rjmccall Date: Mon Oct 29 13:32:36 2018 New Revision: 345536 URL: http://llvm.org/viewvc/llvm-project?rev=345536&view=rev Log: In swiftcall, don't merge FP/vector types within a chunk. Modified: cfe/trunk/include/clang/CodeGen/SwiftCallingConv.h cfe/trunk/lib/CodeGen/SwiftCallingC

Re: r350920 - [Sema] Make canPassInRegisters return true if the CXXRecordDecl passed

On 16 Jan 2019, at 9:13, Aaron Ballman wrote: On Wed, Jan 16, 2019 at 1:57 AM Akira Hatanaka wrote: Yes, the behavior of the compiler doesn’t match what’s explained in the documentation anymore. Please take a look at the attached patch, which updates the documentation. Patch mostly LG

Re: r350920 - [Sema] Make canPassInRegisters return true if the CXXRecordDecl passed

On 16 Jan 2019, at 18:32, Richard Smith wrote: > On Wed, 16 Jan 2019 at 09:10, John McCall via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> On 16 Jan 2019, at 9:13, Aaron Ballman wrote: >> >>> On Wed, Jan 16, 2019 at 1:57 AM Akira Hatanaka >&

Re: r350920 - [Sema] Make canPassInRegisters return true if the CXXRecordDecl passed

On 16 Jan 2019, at 20:03, Richard Smith wrote: > On Wed, 16 Jan 2019 at 16:20, John McCall via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> On 16 Jan 2019, at 18:32, Richard Smith wrote: >> >>> On Wed, 16 Jan 2019 at 09:10, John McCall via cfe-comm

Re: r311065 - Further refactoring of the constant emitter. NFC.

On 18 Mar 2019, at 14:39, Don Hinton wrote: It looks like this change introduced a small bug; Specifically, the following cast test: - if (auto PT = dyn_cast(DestTy)) { ... + // If we're producing a pointer, this is easy. + if (auto destPtrTy = cast(destTy)) { Since the cast can fail, s

Re: r311065 - Further refactoring of the constant emitter. NFC.

On 18 Mar 2019, at 15:38, Don Hinton wrote: Hi John: I found this investigating the cast assert noted here: http://lists.llvm.org/pipermail/cfe-dev/2019-March/061685.html I subsequently did quick grep and found a number of cases in clang+llvm (didn't find any in other projects) . I'm happy t

Re: r311065 - Further refactoring of the constant emitter. NFC.

On 18 Mar 2019, at 18:05, John McCall wrote: On 18 Mar 2019, at 15:38, Don Hinton wrote: Hi John: I found this investigating the cast assert noted here: http://lists.llvm.org/pipermail/cfe-dev/2019-March/061685.html I subsequently did quick grep and found a number of cases in clang+llvm (d

r358104 - Don't emit an unreachable return block.

Author: rjmccall Date: Wed Apr 10 10:03:09 2019 New Revision: 358104 URL: http://llvm.org/viewvc/llvm-project?rev=358104&view=rev Log: Don't emit an unreachable return block. Patch by Brad Moody. Added: cfe/trunk/test/CodeGen/unreachable-ret.c Modified: cfe/trunk/lib/CodeGen/CGCall.cpp

r358115 - Fix an off-by-one mistake in IRGen's copy-construction

Author: rjmccall Date: Wed Apr 10 11:07:18 2019 New Revision: 358115 URL: http://llvm.org/viewvc/llvm-project?rev=358115&view=rev Log: Fix an off-by-one mistake in IRGen's copy-construction special cases in the presence of zero-length arrays. Patch by Joran Bigalet! Modified: cfe/trunk/lib/C

r358125 - Fix for different build configurations.

Author: rjmccall Date: Wed Apr 10 12:11:32 2019 New Revision: 358125 URL: http://llvm.org/viewvc/llvm-project?rev=358125&view=rev Log: Fix for different build configurations. Modified: cfe/trunk/test/CodeGen/unreachable-ret.c Modified: cfe/trunk/test/CodeGen/unreachable-ret.c URL: http://ll

r358132 - Add IRGen APIs to fetch ctor/dtor helper functions for non-trivial structs.

Author: rjmccall Date: Wed Apr 10 12:57:20 2019 New Revision: 358132 URL: http://llvm.org/viewvc/llvm-project?rev=358132&view=rev Log: Add IRGen APIs to fetch ctor/dtor helper functions for non-trivial structs. Patch by Tony Allevato! Modified: cfe/trunk/include/clang/CodeGen/CodeGenABITypes

Re: r358104 - Don't emit an unreachable return block.

al Message- From: cfe-commits On Behalf Of John McCall via cfe-commits Sent: Wednesday, April 10, 2019 10:03 AM To: cfe-commits@lists.llvm.org Subject: r358104 - Don't emit an unreachable return block. Author: rjmccall Date: Wed Apr 10 10:03:09 2019 New Revision: 358104 URL: http://llvm.

Re: [PATCH] D52344: [Clang][CodeGen][ObjC]: Fix non-bridged CoreFoundation builds on ELF targets that use `-fconstant-cfstrings`.

On Sun, Sep 23, 2018 at 5:39 AM David Chisnall via Phabricator < revi...@reviews.llvm.org> wrote: > theraven added a comment. > > In https://reviews.llvm.org/D52344#1242530, @rjmccall wrote: > > > In https://reviews.llvm.org/D52344#1242451, @kristina wrote: > > > > > Would you be okay with me rena

Re: r350920 - [Sema] Make canPassInRegisters return true if the CXXRecordDecl passed

's an important use-case. John. On Jan 16, 2019, at 8:37 PM, John McCall via cfe-commits wrote: On 16 Jan 2019, at 20:03, Richard Smith wrote: On Wed, 16 Jan 2019 at 16:20, John McCall via cfe-commits < cfe-commits@lists.llvm.org> wrote: On 16 Jan 2019, at 18:32, Richard Smith

r362054 - Add the `objc_class_stub` attribute.

Author: rjmccall Date: Wed May 29 21:09:01 2019 New Revision: 362054 URL: http://llvm.org/viewvc/llvm-project?rev=362054&view=rev Log: Add the `objc_class_stub` attribute. Swift requires certain classes to be not just initialized lazily on first use, but actually allocated lazily using informatio

r362183 - Fix the predefined exponent limit macros for the 16-bit IEEE format.

Author: rjmccall Date: Thu May 30 18:21:36 2019 New Revision: 362183 URL: http://llvm.org/viewvc/llvm-project?rev=362183&view=rev Log: Fix the predefined exponent limit macros for the 16-bit IEEE format. The magnitude range of normalized _Float16 is 2^-14 (~6e-5) to (2-2^-10)*2^15 (65504). You m

r368796 - Remove unreachable blocks before splitting a coroutine.

Author: rjmccall Date: Tue Aug 13 20:54:13 2019 New Revision: 368796 URL: http://llvm.org/viewvc/llvm-project?rev=368796&view=rev Log: Remove unreachable blocks before splitting a coroutine. The suspend-crossing algorithm is not correct in the presence of uses that cannot be reached on some succe

r373407 - Emit TypeNodes.def with tblgen.

Author: rjmccall Date: Tue Oct 1 16:13:03 2019 New Revision: 373407 URL: http://llvm.org/viewvc/llvm-project?rev=373407&view=rev Log: Emit TypeNodes.def with tblgen. The primary goal here is to make the type node hierarchy available to other tblgen backends, although it should also make it easie

r373406 - Use scope qualifiers in Clang's tblgen backends to get useful

Author: rjmccall Date: Tue Oct 1 16:12:57 2019 New Revision: 373406 URL: http://llvm.org/viewvc/llvm-project?rev=373406&view=rev Log: Use scope qualifiers in Clang's tblgen backends to get useful redeclaration checking. NFC. Modified: cfe/trunk/utils/TableGen/ClangASTNodesEmitter.cpp cf

r373416 - Remove TypeNodes.def from the modulemap.

Author: rjmccall Date: Tue Oct 1 18:02:27 2019 New Revision: 373416 URL: http://llvm.org/viewvc/llvm-project?rev=373416&view=rev Log: Remove TypeNodes.def from the modulemap. We currently just look for files named in the modulemap in its associated source directory. This means that we can't nam

Re: r373407 - Emit TypeNodes.def with tblgen.

sites. That said, I could certainly go rename it as a follow-up just to re-establish that consistent naming convention. John. On Tue, Oct 1, 2019 at 7:10 PM John McCall via cfe-commits < cfe-commits@lists.llvm.org> wrote: Author: rjmccall Date: Tue Oct 1 16:13:03 2019 New Revision: 373407

r373425 - Rename TypeNodes.def to TypeNodes.inc for consistency across all

Author: rjmccall Date: Tue Oct 1 23:35:23 2019 New Revision: 373425 URL: http://llvm.org/viewvc/llvm-project?rev=373425&view=rev Log: Rename TypeNodes.def to TypeNodes.inc for consistency across all our autogenerated files. NFC. As requested by Nico Weber. Modified: cfe/trunk/include/clang

Re: r373407 - Emit TypeNodes.def with tblgen.

just to re-establish that consistent naming convention. John. On Tue, Oct 1, 2019 at 7:10 PM John McCall via cfe-commits < cfe-commits@lists.llvm.org> wrote: Author: rjmccall Date: Tue Oct 1 16:13:03 2019 New Revision: 373407 URL: http://llvm.org/viewvc/llvm-project?rev=373407&am

Re: r373406 - Use scope qualifiers in Clang's tblgen backends to get useful

4:10 PM John McCall via cfe-commits < cfe-commits@lists.llvm.org> wrote: Author: rjmccall Date: Tue Oct 1 16:12:57 2019 New Revision: 373406 URL: http://llvm.org/viewvc/llvm-project?rev=373406&view=rev Log: Use scope qualifiers in Clang's tblgen backends to get useful redeclar

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

(Sorry for the delay in responding — I'm actually on vacation.) On Tue, Apr 10, 2018 at 1:52 PM, David Blaikie wrote: > On Tue, Apr 10, 2018 at 10:20 AM John McCall wrote: > >> Do you think they’re bad precedent? > > > Somewhat, yes - though -Wparens is perhaps conflating a few cases too. I > t

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

> On Apr 9, 2018, at 3:47 PM, Akira Hatanaka wrote: > > >> On Apr 5, 2018, at 1:25 PM, John McCall > > wrote: >> >> >> >>> On Apr 5, 2018, at 3:54 PM, Akira Hatanaka >> > wrote: >>> >>> On Apr 5, 2018, at 12:39 PM, John McCall >>>

Re: [PATCH] D45685: [Sema] Add -wtest global flag that silences -Wself-assign for overloaded operators.

Let me try to summarize where I think we are. 1. I think it’s now generally agreed that this is a useful warning — certainly for field assignments, but we also have (at least?) one example with a local variable. 2. It’s also generally agreed that this warning has a problem with unit tests and tha

Re: [PATCH] D45766: [Sema] Add -Wno-self-assign-overloaded

On Mon, Apr 23, 2018 at 6:32 PM, David Blaikie wrote: > On Mon, Apr 23, 2018 at 3:29 PM John McCall via Phabricator < > revi...@reviews.llvm.org> wrote: > >> rjmccall added a comment. >> >> In https://reviews.llvm.org/D45766#1076176, @dblaikie wrote: >> >> > Is there anything else in the "-w" nam

Re: [PATCH] D45766: [Sema] Add -Wno-self-assign-overloaded

On Mon, Apr 23, 2018 at 8:23 PM, Richard Smith wrote: > On 23 April 2018 at 16:23, David Blaikie via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> On Mon, Apr 23, 2018 at 4:12 PM John McCall wrote: >> >>> On Mon, Apr 23, 2018 at 6:32 PM, David Blaikie >>> wrote: >>> On Mon, Apr 2

Re: [PATCH] D45476: [C++2a] Implement operator<=> CodeGen and ExprConstant

I think you and Richard agreed that you weren’t going to synthesize a whole expression tree at every use of the operator, and I agree with that decision. That’s very different from what I’m asking you to do, which is to synthesize in isolation a call to the copy-constructor. There are several place

[clang] baf91d0 - [NFC] Add a tablegen node for the root of the AST node hierarchies.

Author: John McCall Date: 2019-10-25T16:39:21-07:00 New Revision: baf91d02da6e68c4ee6723ef68911fcd80ece6a5 URL: https://github.com/llvm/llvm-project/commit/baf91d02da6e68c4ee6723ef68911fcd80ece6a5 DIFF: https://github.com/llvm/llvm-project/commit/baf91d02da6e68c4ee6723ef68911fcd80ece6a5.diff L

[clang] 8a8d703 - Fix how cc1 command line options are mapped into FP options.

Author: John McCall Date: 2020-06-01T22:00:30-04:00 New Revision: 8a8d703be0986dd6785cba0b610c9c4708b83e89 URL: https://github.com/llvm/llvm-project/commit/8a8d703be0986dd6785cba0b610c9c4708b83e89 DIFF: https://github.com/llvm/llvm-project/commit/8a8d703be0986dd6785cba0b610c9c4708b83e89.diff L

[clang] 7fac1ac - Set the LLVM FP optimization flags conservatively.

Author: John McCall Date: 2020-06-11T18:16:41-04:00 New Revision: 7fac1acc617113b7a3276ee0f0664bedca978292 URL: https://github.com/llvm/llvm-project/commit/7fac1acc617113b7a3276ee0f0664bedca978292 DIFF: https://github.com/llvm/llvm-project/commit/7fac1acc617113b7a3276ee0f0664bedca978292.diff L

[clang] 32870a8 - Expose IRGen API to add the default IR attributes to a function definition.

Author: John McCall Date: 2020-05-16T14:44:54-04:00 New Revision: 32870a84d9a40ea682e22a24b5f0d1a218c3b062 URL: https://github.com/llvm/llvm-project/commit/32870a84d9a40ea682e22a24b5f0d1a218c3b062 DIFF: https://github.com/llvm/llvm-project/commit/32870a84d9a40ea682e22a24b5f0d1a218c3b062.diff L

Re: [PATCH] D24712: Replace 'isProvablyNonNull' with existing utility llvm::IsKnownNonNull.

rjmccall added a comment. The formation restrictions on ARC writeback conversions probably make this more-or-less impossible to test, but I can try to explain when they happen. They happen when you have an argument of type "id __strong *" and pass it as a parameter of type "id __autoreleasing

Re: [PATCH] D24712: Replace 'isProvablyNonNull' with existing utility llvm::IsKnownNonNull.

rjmccall added a comment. Actually, that should demonstrate the difference, assuming the LLVM function looks through selects, since IRGen should generate that as a select. https://reviews.llvm.org/D24712 ___ cfe-commits mailing list cfe-commits@lis

Re: [PATCH] D24712: Replace 'isProvablyNonNull' with existing utility llvm::IsKnownNonNull.

rjmccall added a comment. Oh. One danger with invoking a generic LLVM routine is that they often expect a well-formed function, not something that is plausibly still being emitted. https://reviews.llvm.org/D24712 ___ cfe-commits mailing list cfe-c

Re: [PATCH] D24712: Replace 'isProvablyNonNull' with existing utility llvm::IsKnownNonNull.

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. In that case, you probably will not be able to test this difference, because the argument is basically required to be the address of a local variable, a parameter, or null (or a various th

[PATCH] D24012: Fix strict-aliasing violation in typeinfo::hash_code()

rjmccall added a comment. LGTM, but I'm not a code owner here. https://reviews.llvm.org/D24012 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

rjmccall added inline comments. Comment at: lib/CodeGen/CGDecl.cpp:1291 +// where the pointer to the local variable is the key in the map. +void CodeGenFunction::EmitAutoVarNoAlias(const AutoVarEmission &emission) { + assert(emission.Variable && "emission was not valid!"); -

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

rjmccall requested changes to this revision. rjmccall added inline comments. This revision now requires changes to proceed. Comment at: lib/CodeGen/CodeGenFunction.h:379 + /// Set of object pointers which are blacklisted from the UB sanitizer. + llvm::SmallPtrSet SanitizerBaseP

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

rjmccall added a comment. The correct fix is to honor isInit by folding the logic for EmitScalarInit into this function. That should allow you to eliminate EmitScalarInit completely, although it would be fine to leave it as just a call to EmitStoreThroughLValue. I did a quick audit of all the

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

rjmccall added a comment. Richard should probably weigh in about whether we should be recording potential captures at *all* capturing scopes. But at the very least, I think you have a bug here where the variable is declared outside of the block but within the lambda; in that case, it is defini

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

rjmccall added a comment. Wait, can you talk me through the bug here? Why is final-based devirtualization here different from, say, user-directed devirtualization via a qualified method name? It sounds to me from your description that you're not sure why this is happening. If this indeed onl

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

rjmccall added a comment. Sorry, no, just the one that takes an llvm::Value* instead of an Expr*. https://reviews.llvm.org/D25547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

rjmccall added inline comments. Comment at: lib/CodeGen/CGExpr.cpp:1650 +} + switch (Lifetime) { I think you can fold this a bit more. :) You have exactly the same switch statement below, and several of the cases are identical; for the others, you can

Re: [PATCH] D41039: Add support for attribute "trivial_abi"

On Mon, Dec 11, 2017 at 6:19 PM, David Blaikie wrote: > On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator < > revi...@reviews.llvm.org> wrote: > >> rjmccall added a comment. >> >> In https://reviews.llvm.org/D41039#951648, @ahatanak wrote: >> >> > I had a discussion with Duncan today an

Re: [PATCH] D41039: Add support for attribute "trivial_abi"

On Tue, Dec 12, 2017 at 1:45 PM, David Blaikie wrote: > On Mon, Dec 11, 2017 at 5:38 PM John McCall wrote: > >> On Mon, Dec 11, 2017 at 6:19 PM, David Blaikie >> wrote: >> >>> On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator < >>> revi...@reviews.llvm.org> wrote: >>> rjmccall ad

[clang] [ObjC] Fix offsets following `[[no_unique_address]]` for `@encode()` (PR #71321)

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

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

rjmccall wrote: > pragma pack uses pragma stack and it is allowed in any place: > https://godbolt.org/z/f8fP1vn63 . If such pragma presents in the late-parsed > template, and push-pop operations in it are not balanced, the late parse of > such function can break the pragma stack and next templ

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

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

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

@@ -710,9 +710,11 @@ class Sema final { return result; } + // Saves the current floating-point pragma stack and clear it in this Sema. class FpPragmaStackSaveRAII { public: -FpPragmaStackSaveRAII(Sema &S) : S(S), SavedStack(S.FpPragmaStack) {} +FpPragmaSta

[clang] [clang] Do not clear FP pragma stack when instantiating functions (PR #70646)

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

[clang] [clang] Remove fixed point arithmetic error (PR #71884)

rjmccall wrote: I'm happy with the basic idea here of making fixed-point an opt-in feature. It'd be nice to preserve the special diagnostic that tells the user that they need to use `-ffixed-point`, though. Do we have any existing parsing paths that recognize unrecognized identifiers that ar

[clang] Ignore template parameter visibility (PR #72092)

rjmccall wrote: Can we just ignore template parameters selectively when we have a visibility attribute, the way I suggested in https://reviews.llvm.org/D154774? To quote: > A visibility attribute on an explicit specialization or instantiation should > definitely override everything else. A v

[clang] [ARC][Documentation] Explicitly state that messaging weak objects keeps a strong reference during call lifetime (PR #72169)

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

[clang] Ignore template parameter visibility (PR #72092)

rjmccall wrote: > I cannot figure out a test case for `TemplateArgument::Expression`. I wonder > whether it applies to `X<&s.s> x5;` (address of static member), which Clang > doesn't support. It's primarily used as a dependent template argument. I'm not sure off-hand that it's *never* canoni

[clang] [Clang] Emit TBAA info for enums in C (PR #73326)

rjmccall wrote: This seems conservatively correct, yeah. My reading is that we could also use the underlying type as a parent type for the TBAA metadata: enums are compatible with their underlying type, but two enums with the same underlying type are not compatible with each other. But this

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

rjmccall wrote: > @rjmccall The problem will arise only if GCC implements support for MSVC C++ > ABI and decides that there is a better way to implement `gcc_struct`. Since, > AFAIC, MSVC-compatibility for GCC is not even planned, it's unlikely anybody > there will have strong opinions on this

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

rjmccall wrote: Right, I'd just like to make sure that we're not deepening a divergence here. It would be good to get agreement from the GCC devs that they think `ms_struct` probably ought to do something on e.g. ARM MinGW targets and that they consider this a bug (in a feature that they may

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

@@ -5587,10 +5593,12 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo &CallInfo, !isa_and_nonnull(TargetDecl)) EmitKCFIOperandBundle(ConcreteCallee, BundleList); +#if 0 // XXX Why is this here? Duplicate! if (const FunctionDecl *FD = dyn_cast_or_null(CurF

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

@@ -6,14 +7,80 @@ float z(); #pragma float_control(except, on) class ON { float w = 2 + y() * z(); - // CHECK-LABEL: define {{.*}} @_ZN2ONC2Ev{{.*}} - // CHECK: llvm.experimental.constrained.fmul{{.*}}tonearest{{.*}}strict }; ON on; #pragma float_control(except, off) cl

[clang] [llvm] [CodeGen][arm64e] Add methods and data members to Address, which are needed to authenticate signed pointers (PR #67454)

@@ -232,110 +279,133 @@ class CGBuilderTy : public CGBuilderBaseTy { /// where i64 is actually the target word size. Address CreateConstGEP(Address Addr, uint64_t Index, const llvm::Twine &Name = "") { +llvm::Type *ElTy = Addr.getElementType();

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

@@ -7255,20 +7255,27 @@ void Sema::CheckCompletedCXXClass(Scope *S, CXXRecordDecl *Record) { CheckCompletedMemberFunction(MD); } - // ms_struct is a request to use the same ABI rules as MSVC. Check - // whether this class uses any C++ features that are implemented

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

@@ -5031,7 +5031,12 @@ void RecordDecl::completeDefinition() { /// This which can be turned on with an attribute, pragma, or the /// -mms-bitfields command-line option. bool RecordDecl::isMsStruct(const ASTContext &C) const { - return hasAttr() || C.getLangOpts().MSBitfields =

[clang] Ignore template parameter visibility (PR #72092)

rjmccall wrote: The basic design idea behind Clang's visibility model is to treat hidden visibility as essentially a second grade of external linkage, external to the translation unit but internal to the linkage unit (i.e. image). So what you pointed out about using an anonymous namespace is

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

@@ -5031,7 +5031,12 @@ void RecordDecl::completeDefinition() { /// This which can be turned on with an attribute, pragma, or the /// -mms-bitfields command-line option. bool RecordDecl::isMsStruct(const ASTContext &C) const { - return hasAttr() || C.getLangOpts().MSBitfields =

[clang] [clang] Remove fixed point arithmetic error (PR #71884)

rjmccall wrote: I definitely don't think we should be handling this in the lexer by trying to retroactively make this a keyword. I was just thinking that we might have some sort of parser-level recovery for e.g. `unrecognized_identifier_t x = 5;` that might guess that `unrecognized_identifier_

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

@@ -5031,7 +5031,12 @@ void RecordDecl::completeDefinition() { /// This which can be turned on with an attribute, pragma, or the /// -mms-bitfields command-line option. bool RecordDecl::isMsStruct(const ASTContext &C) const { - return hasAttr() || C.getLangOpts().MSBitfields =

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

rjmccall wrote: I agree with the Sema/AST-level LGTM (but also don't feel comfortable approving the driver changes) https://github.com/llvm/llvm-project/pull/71148 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

rjmccall wrote: First off, the change here actually applies to all over-aligned empty structs, not just to those with aligned bit-fields. Maybe we can say that aligned zero-width bit-fields are ill-formed, but I don't think we can say that all aligned empty classes are ill-formed, among other

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

rjmccall wrote: Oh, the [Apple AArch64 calling convention](https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Pass-arguments-to-functions-correctly) diverges from AAPCS and ignores empty classes as parameters. We appear to consider this an empty class regar

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

https://github.com/rjmccall requested changes to this pull request. Marking as changes requested so that this doesn't get committed. https://github.com/llvm/llvm-project/pull/72197 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.l

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

rjmccall wrote: > This is the code I debug located. Seem the comment is out of date? That seems like the right place to fix the issue, specifically the place below where it always passes a single `i8`. The right rule is to just fall through to the normal conventions for passing the argument i

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

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

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

rjmccall wrote: > The code you noted is supposed to handle two cases, neither of which are > relevant to your testcase: > > * Darwin-specific calling convention rules. > * GNU extensions for zero-size structs (which aren't allowed according to > either C or C++ standards, but GNU invented a bu

[clang] fix: compatible C++ empty record with align UB with gcc (PR #72197)

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

[clang] [clang] Ensure fixed point conversions work in C++ (PR #68344)

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

[clang] [AVR] make the AVR ABI Swift compatible (PR #72298)

rjmccall wrote: Right, that would be the way to test it. I don't know much about AVR, but you should also look at some of the parameters to the lowering (e.g. how many max values it's okay to break an aggregate into) and make sure you're happy with them. https://github.com/llvm/llvm-project/p

[clang] [AVR] make the AVR ABI Swift compatible (PR #72298)

rjmccall wrote: > @efriedma-quic Cool. So it sounds like it's worth parking this for now, until > Kuba's work #71986 is merged? > > @rjmccall I'm not 100% sure I understand? The existing code in AVR.cpp > handles the standard AVR ABI, which has a few simple rules based on GCC > behaviour. Her

  1   2   3   4   5   6   7   8   9   10   >