Page MenuHomePhabricator
Feed Advanced Search

Yesterday

rjmccall added inline comments to D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior.
Wed, Oct 16, 3:26 PM · Restricted Project
rjmccall added a comment to D68818: [hip][cuda] Fix the extended lambda name mangling issue..

I agree with Richard's suggestion of just numbering all the lambdas in both modes if that's viable.

Wed, Oct 16, 3:26 PM · Restricted Project

Tue, Oct 8

rjmccall added inline comments to D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior.
Tue, Oct 8, 8:31 PM · Restricted Project
rjmccall accepted D68611: [IRGen] Emit lifetime markers for temporary struct allocas.

LGTM

Tue, Oct 8, 1:14 PM · Restricted Project
rjmccall added inline comments to D68611: [IRGen] Emit lifetime markers for temporary struct allocas.
Tue, Oct 8, 10:06 AM · Restricted Project
rjmccall added a comment to D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior.

Thank you, this looks very clean now.

Tue, Oct 8, 10:06 AM · Restricted Project

Tue, Oct 1

rjmccall committed rG36b12a861c4f: Rename TypeNodes.def to TypeNodes.inc for consistency across all our… (authored by rjmccall).
Rename TypeNodes.def to TypeNodes.inc for consistency across all our…
Tue, Oct 1, 11:41 PM
rjmccall committed rL373425: Rename TypeNodes.def to TypeNodes.inc for consistency across all.
Rename TypeNodes.def to TypeNodes.inc for consistency across all
Tue, Oct 1, 11:34 PM
rjmccall committed rGc60a8242056b: Remove TypeNodes.def from the modulemap. (authored by rjmccall).
Remove TypeNodes.def from the modulemap.
Tue, Oct 1, 6:02 PM
rjmccall committed rL373416: Remove TypeNodes.def from the modulemap..
Remove TypeNodes.def from the modulemap.
Tue, Oct 1, 6:00 PM
rjmccall committed rGa82d2fe94427: Emit TypeNodes.def with tblgen. (authored by rjmccall).
Emit TypeNodes.def with tblgen.
Tue, Oct 1, 4:12 PM
rjmccall committed rGc45f8d49897f: Use scope qualifiers in Clang's tblgen backends to get useful redeclaration… (authored by rjmccall).
Use scope qualifiers in Clang's tblgen backends to get useful redeclaration…
Tue, Oct 1, 4:12 PM
rjmccall committed rL373407: Emit TypeNodes.def with tblgen..
Emit TypeNodes.def with tblgen.
Tue, Oct 1, 4:12 PM
rjmccall committed rL373406: Use scope qualifiers in Clang's tblgen backends to get useful.
Use scope qualifiers in Clang's tblgen backends to get useful
Tue, Oct 1, 4:11 PM

Sat, Sep 28

rjmccall added a comment to D68108: Redeclare Objective-C property accessors inside the ObjCImplDecl in which they are synthesized..

Also, I think it would be good if there was a more explicit method for asking whether a method is a synthesized definition. Basically, there's a tri-state: there are pure declarations, user-provided definitions, and synthetic definitions. IRGen should emit a function when it sees either of the latter two, but it might have to use special code for synthetic definitions.

Sat, Sep 28, 12:04 AM · Restricted Project

Fri, Sep 27

rjmccall added inline comments to D68108: Redeclare Objective-C property accessors inside the ObjCImplDecl in which they are synthesized..
Fri, Sep 27, 11:55 PM · Restricted Project

Wed, Sep 25

rjmccall added inline comments to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
Wed, Sep 25, 11:03 PM
rjmccall accepted D67983: [ObjC] Diagnose implicit type coercion from ObjC 'Class' to object pointer types..

LGTM.

Wed, Sep 25, 2:56 PM · Restricted Project
rjmccall accepted D67982: [ObjC] Add some additional test cases around pointer conversions..

LGTM.

Wed, Sep 25, 2:56 PM · Restricted Project
rjmccall added a comment to D67837: [CUDA][HIP] Fix host/device check with -fopenmp.

That looks great. I'm probably not the best person to validate that the OMP / CUDA logic is still right, but it seems like the right technical design.

Wed, Sep 25, 2:41 PM · Restricted Project
rjmccall added inline comments to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
Wed, Sep 25, 2:41 PM
rjmccall accepted D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing.

Thanks, LGTM.

Wed, Sep 25, 10:28 AM · Restricted Project
rjmccall added a comment to D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing.

Thanks. One last and minor request: please mention in the comment on IsLiteralLabel that non-literal labels are used by some external AST sources like LLDB.

Wed, Sep 25, 1:55 AM · Restricted Project

Tue, Sep 24

rjmccall added inline comments to D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing.
Tue, Sep 24, 5:15 PM · Restricted Project
rjmccall added a comment to D67837: [CUDA][HIP] Fix host/device check with -fopenmp.

If that's tractable, then that does seem like the best solution. You can commit this if you need a shorter-term fix.

Tue, Sep 24, 10:49 AM · Restricted Project

Mon, Sep 23

rjmccall added inline comments to D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing.
Mon, Sep 23, 2:00 PM · Restricted Project
rjmccall added a comment to D67837: [CUDA][HIP] Fix host/device check with -fopenmp.

Okay. And it's okay to fall down to the code below when functions are used in both ways this way?

Mon, Sep 23, 1:15 PM · Restricted Project

Fri, Sep 20

rjmccall added inline comments to D67837: [CUDA][HIP] Fix host/device check with -fopenmp.
Fri, Sep 20, 4:01 PM · Restricted Project
rjmccall added inline comments to D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing.
Fri, Sep 20, 3:59 PM · Restricted Project
rjmccall added inline comments to D67837: [CUDA][HIP] Fix host/device check with -fopenmp.
Fri, Sep 20, 9:50 AM · Restricted Project

Thu, Sep 19

rjmccall added inline comments to D67774: [Mangle] Add flag to asm labels to disable '\01' prefixing.
Thu, Sep 19, 1:31 PM · Restricted Project

Tue, Sep 17

rjmccall added a comment to D66121: Debug Info: Nest Objective-C property function decls inside their container..

I'm afraid I'm going to give up on fixing the AST and return to my debuginfo-only patch.

While I was correct in figuring out that ObjCMethodDecl implementations are not linked up as redeclarations of ObjCMethodDecl decls in the interface, that wasn't the whole story: ObjCMethodDecl::getNextRedeclarationImpl() links them up *implicitly* by finding the implementation for a decl and vice versa by looking up the selector in the interface/implementation (See https://github.com/llvm/llvm-project/blob/244e738485445fa4b72bfef9b9b2f9625cee989e/clang/lib/AST/DeclObjC.cpp#L905).

I can make this mechanism work by adding the method to the ObjCImplementationDecl, so it gets found by getNextRedeclarationImpl(). But if I do that, CodeGen falls over completely, because the new property accessor redeclarations don't actually have any function bodies. CodeGen in several places special-cases property accessors to generate them on-the-fly. I think this may work neatly if we actually created an AST for the function body in SemaObjCProperty too, and remove the functionality from CodeGen, but that is beyond what I'm prepared to do.

Tue, Sep 17, 5:51 PM · debug-info

Sep 16 2019

rjmccall accepted D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.

LGTM, thank you.

Sep 16 2019, 12:52 PM · Restricted Project
rjmccall added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 16 2019, 12:30 PM · Restricted Project

Sep 13 2019

rjmccall added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 13 2019, 2:11 PM · Restricted Project
rjmccall added a comment to D67399: [ARM] Follow AACPS standard for volatile bitfields.
In D67399#1669568, @jfb wrote:

Indeed our main concern is regarding the access widths of loads. As mentioned by @rjmccall, most volatile bitfields are used to perform memory mapped I/O, and some hardware only support them with a specific access width.
The spurious load I am more than glad to leave it disable behind a command flag, so it will only appear if the user requests it. See that volatile accesses might have side effects, and for example, an I/O read counter holding an odd number could define that the data is still being processed.

Are the cases being addressed in the PR actually relevant to real MMIO, or is this patch following the letter of AAPCS which doesn't actually matter?

Sep 13 2019, 12:53 PM · Restricted Project
rjmccall added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 13 2019, 12:51 PM · Restricted Project

Sep 12 2019

rjmccall added a comment to D67399: [ARM] Follow AACPS standard for volatile bitfields.

I have to say that I disagree. The ABI certainly doesn't get to control the language and define what constitutes a volatile access, but when the language has decided that a volatile access is actually performed, I think ABIs absolutely ought to define how they should be compiled. Volatile accesses are quite unusual in that they are used for a purpose — memory-mapped I/O — that is extremely dependent for correctness on the exact instructions used to implement it. IIRC there are architectures that for whatever reason provide two different load instructions where only one of those instructions actually performs memory-mapped I/O correctly. Certainly the exact width of load or store is critical for correctness. So while I have certainly seen ABI overreach before and pushed back on it, for this one case I think ABI involvement is totally appropriate, and in fact I wish more ABIs specified how they expect volatile accesses to be performed.

Sep 12 2019, 9:56 PM · Restricted Project
rjmccall added a comment to D67399: [ARM] Follow AACPS standard for volatile bitfields.

The exact sequence of volatile accesses is observable behavior, and it's the ABI's right to define correct behavior for compliant implementations, so we do need to do this.

Sep 12 2019, 5:12 PM · Restricted Project
rjmccall added a comment to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.

Thanks! Some wording suggestions.

Sep 12 2019, 3:24 PM · Restricted Project
rjmccall added a reviewer for D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior': scanon.
Sep 12 2019, 2:03 PM · Restricted Project

Sep 11 2019

rjmccall accepted D67429: Improve code generation for thread_local variables:.

LGTM.

Sep 11 2019, 12:03 PM · Restricted Project, Restricted Project
rjmccall added a comment to D66121: Debug Info: Nest Objective-C property function decls inside their container..

Right, that sounds reasonable. You should be making them link up exactly like a normal method implementation, so if SemaObjC doesn't consider normal method implementations to be redeclarations, then I guess these aren't either. And if we want to change that in the future, then we'll change it for these, too.

Sep 11 2019, 12:02 PM · debug-info

Sep 9 2019

rjmccall added a comment to D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior.

Hmm, you know, there are enough different FP options that I think we should probably split them all out into their own section in the manual instead of just listing them under "code generation". That will also give us an obvious place to describe the basic model, i.e. all the stuff about it mostly coming down to different strictness and exception models. Could you prepare a patch that *just* does that reorganization without adding any new features, and then we can add the new options on top of that?

Sep 9 2019, 1:40 PM · Restricted Project
rjmccall updated subscribers of D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior.

I think this is a step in the right direction, thank you. I'd like @scanon to weigh in on the evolving design here.

Sep 9 2019, 10:15 AM · Restricted Project

Sep 6 2019

rjmccall accepted D65256: [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownership qualifications as unavailable if the union is declared in a system header.

Okay, thanks. LGTM.

Sep 6 2019, 4:12 PM · Restricted Project, Restricted Project
rjmccall added inline comments to D65256: [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownership qualifications as unavailable if the union is declared in a system header.
Sep 6 2019, 11:15 AM · Restricted Project, Restricted Project
rjmccall added a comment to D67291: Teach the IRBuilder about constrained FPToSI and FPToUI.

LGTM

Sep 6 2019, 10:57 AM · Restricted Project

Sep 5 2019

rjmccall added a comment to D65256: [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownership qualifications as unavailable if the union is declared in a system header.

Could you give it a slightly more general name and then use it in the main semantic check in ActOnFields?

Sep 5 2019, 10:06 AM · Restricted Project, Restricted Project

Sep 4 2019

rjmccall added inline comments to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
Sep 4 2019, 1:56 PM
rjmccall added inline comments to D65256: [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownership qualifications as unavailable if the union is declared in a system header.
Sep 4 2019, 12:57 PM · Restricted Project, Restricted Project

Sep 3 2019

rjmccall added a comment to D66121: Debug Info: Nest Objective-C property function decls inside their container..

Can you prepare an NFC patch with just the changes relating to adding ObjCPropertyImplDecl::get{Getter,Setter}MethodDecl?

Sep 3 2019, 2:54 PM · debug-info
rjmccall added a comment to D65256: [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownership qualifications as unavailable if the union is declared in a system header.

Okay, now that I understand the source-compatibility issues a little better, I think this approach is probably okay. If it causes trouble, we can consider special-casing these headers to treat the member as __unsafe_unretained implicitly — the special case isn't great, but it's better than the potential unsoundness.

Sep 3 2019, 2:35 PM · Restricted Project, Restricted Project

Aug 30 2019

rjmccall added a comment to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.

I don't think this is likely to change. Are you suggesting to move the deduction logic for pointee of pointers, references and block pointers into ASTContext helper that creates a pointer/reference/block pointer type?

Aug 30 2019, 12:37 PM

Aug 27 2019

rjmccall added inline comments to D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior.
Aug 27 2019, 11:34 AM · Restricted Project

Aug 26 2019

rjmccall added inline comments to D66360: Expose constructing a virtual method dispatch through the include/clang/CodeGen APIs..
Aug 26 2019, 10:22 PM · Restricted Project
rjmccall added inline comments to D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior.
Aug 26 2019, 10:03 PM · Restricted Project
rjmccall added a comment to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.

I see. Is the deduction rule recursive or something, where a pointer to pointer is inferred to point to the same address space as the pointee?

It is recursive indeed and we currently deduce all pointees to generic AS.

Aug 26 2019, 9:48 PM
rjmccall added inline comments to D64811: Warn when NumParams overflows.
Aug 26 2019, 9:43 PM · Restricted Project

Aug 16 2019

rjmccall added a comment to D66230: [coroutine] Fixes "cannot move instruction since its users are not dominated by CoroBegin" problem..

aspects of frame layout being exposed in the ABI is a property of the switch lowering, not coroutines in general.

You may be right. Given that now we have two frontends targeting LLVM Coroutines, some refactoring may be in order. I need to study more the Swift approach before I can form an opinion.

Marking it as NoDuplicate in CoroEarly helps simplify the CoroSplit logic.

Does it? Why? There already has to be a single coro.id in the coroutine, and that's the intrinsic that takes useful information. coro.begin just has a bunch of requirements and no clear purpose except to return the frame, which could just as well be done with a duplicable intrinsic.

Here is how it looks to me: C++ frontends emits the following structure (simplified):

%id = coro.id(stuff)
%mem = SomeAllocCodeCouldBeAnything(stuff)
%frame = coro.begin(%mem)

coro.begin "blesses" the memory as the one to be used in the coroutine and therefore should dominate any possible uses of data that go into the coroutine frame and gives a convenient place to dump spills, copies, etc.

If we did not allow arbitrary allocation logic in c++, there would be no need for coro.begin at all.

Aug 16 2019, 11:54 PM · Restricted Project

Aug 15 2019

rjmccall added a comment to D66230: [coroutine] Fixes "cannot move instruction since its users are not dominated by CoroBegin" problem..

Is there a case you're imagining where the adjustment would have side-effects? Because I can see a reason to have an intrinsic that returns a frame pointer, but I don't see why that intrinsic would have any of the restrictions of @llvm.coro.begin.

Which restrictions are you thinking about?

Aug 15 2019, 10:00 PM · Restricted Project
rjmccall added a comment to D66230: [coroutine] Fixes "cannot move instruction since its users are not dominated by CoroBegin" problem..

Is there a case you're imagining where the adjustment would have side-effects? Because I can see a reason to have an intrinsic that returns a frame pointer, but I don't see why that intrinsic would have any of the restrictions of @llvm.coro.begin.

Aug 15 2019, 5:41 PM · Restricted Project

Aug 14 2019

rjmccall added a comment to D66230: [coroutine] Fixes "cannot move instruction since its users are not dominated by CoroBegin" problem..

Seems reasonable to me. If we're no longer imposing any *restrictions* for @llvm.coro.begin, is it serving any real purpose? Is it just a way of getting a handle to the coroutine frame?

Aug 14 2019, 9:40 PM · Restricted Project
rjmccall added a comment to rG038d604f4f8c: [SimplifyLibCalls] Add noalias from known callsites.

As a frontend author, I would like to be able to conveniently copy memory for a struct assignment in a single line of IR.

memmove? :) this needs new benchmarks

Aug 14 2019, 8:27 AM

Aug 13 2019

rjmccall committed rGa318c5507348: Coroutines: adjust for SVN r358739 (authored by rjmccall).
Coroutines: adjust for SVN r358739
Aug 13 2019, 8:57 PM
rjmccall committed rG3bbf207fbc56: Don't run a full verifier pass in coro-splitting's private pipeline. (authored by rjmccall).
Don't run a full verifier pass in coro-splitting's private pipeline.
Aug 13 2019, 8:56 PM
rjmccall committed rG5f60b68c68c0: Remove unreachable blocks before splitting a coroutine. (authored by rjmccall).
Remove unreachable blocks before splitting a coroutine.
Aug 13 2019, 8:56 PM
rjmccall committed rG2133feec933e: Support swifterror in coroutine lowering. (authored by rjmccall).
Support swifterror in coroutine lowering.
Aug 13 2019, 8:56 PM
rjmccall committed rGdc4668e5cf91: Update for optimizer changes. (authored by rjmccall).
Update for optimizer changes.
Aug 13 2019, 8:56 PM
rjmccall committed rGd47801e7182a: In coro.retcon lowering, don't explode if the optimizer messes around with the… (authored by rjmccall).
In coro.retcon lowering, don't explode if the optimizer messes around with the…
Aug 13 2019, 8:56 PM
rjmccall committed rGac404832760a: Fix a use-after-free in the coro.alloca treatment. (authored by rjmccall).
Fix a use-after-free in the coro.alloca treatment.
Aug 13 2019, 8:56 PM
rjmccall committed rG62a5dde0c29f: Add intrinsics for doing frame-bound dynamic allocations within a coroutine. (authored by rjmccall).
Add intrinsics for doing frame-bound dynamic allocations within a coroutine.
Aug 13 2019, 8:56 PM
rjmccall committed rG137b50f0c3b1: Guard dumps in the coro intrinsic validation logic behind NDEBUG checks. dump()… (authored by rjmccall).
Guard dumps in the coro intrinsic validation logic behind NDEBUG checks. dump()…
Aug 13 2019, 8:56 PM
rjmccall committed rG382921418554: Generalize llvm.coro.suspend.retcon to allow an arbitrary number of arguments… (authored by rjmccall).
Generalize llvm.coro.suspend.retcon to allow an arbitrary number of arguments…
Aug 13 2019, 8:56 PM
rjmccall committed rG94010b2b7f47: Extend coroutines to support a "returned continuation" lowering. (authored by rjmccall).
Extend coroutines to support a "returned continuation" lowering.
Aug 13 2019, 8:56 PM
rjmccall committed rL368798: Coroutines: adjust for SVN r358739.
Coroutines: adjust for SVN r358739
Aug 13 2019, 8:55 PM
rjmccall committed rL368797: Don't run a full verifier pass in coro-splitting's private pipeline..
Don't run a full verifier pass in coro-splitting's private pipeline.
Aug 13 2019, 8:55 PM
rjmccall committed rL368796: Remove unreachable blocks before splitting a coroutine..
Remove unreachable blocks before splitting a coroutine.
Aug 13 2019, 8:55 PM
rjmccall committed rL368795: Support swifterror in coroutine lowering..
Support swifterror in coroutine lowering.
Aug 13 2019, 8:55 PM
rjmccall committed rL368794: Update for optimizer changes..
Update for optimizer changes.
Aug 13 2019, 8:55 PM
rjmccall committed rL368793: In coro.retcon lowering, don't explode if the optimizer messes around with the….
In coro.retcon lowering, don't explode if the optimizer messes around with the…
Aug 13 2019, 8:55 PM
rjmccall committed rL368792: Fix a use-after-free in the coro.alloca treatment..
Fix a use-after-free in the coro.alloca treatment.
Aug 13 2019, 8:55 PM
rjmccall committed rL368791: Add intrinsics for doing frame-bound dynamic allocations within a coroutine..
Add intrinsics for doing frame-bound dynamic allocations within a coroutine.
Aug 13 2019, 8:55 PM
rjmccall committed rL368790: Guard dumps in the coro intrinsic validation logic behind NDEBUG checks. dump()….
Guard dumps in the coro intrinsic validation logic behind NDEBUG checks. dump()…
Aug 13 2019, 8:55 PM
rjmccall committed rL368789: Generalize llvm.coro.suspend.retcon to allow an arbitrary number of arguments….
Generalize llvm.coro.suspend.retcon to allow an arbitrary number of arguments…
Aug 13 2019, 8:55 PM
rjmccall committed rL368788: Extend coroutines to support a "returned continuation" lowering..
Extend coroutines to support a "returned continuation" lowering.
Aug 13 2019, 8:55 PM
rjmccall accepted D27165: Add format_dynamic_key_arg attribute to improve "-Wformat" warnings for functions that load the formatting string dynamically based on a key value.

One minor request (which will be dead code in your patch), but otherwise LGTM.

Aug 13 2019, 4:58 PM · Restricted Project
rjmccall added inline comments to D66094: [CodeGen] Emit destructor calls for non-trivial C structs returned by function calls and loaded from volatile objects.
Aug 13 2019, 4:13 PM · Restricted Project, Restricted Project
rjmccall added a comment to rG038d604f4f8c: [SimplifyLibCalls] Add noalias from known callsites.

I don't think it's generally the frontend's responsibility to decide things like whether to inline memcpy.

Aug 13 2019, 3:21 PM
rjmccall added a comment to D27165: Add format_dynamic_key_arg attribute to improve "-Wformat" warnings for functions that load the formatting string dynamically based on a key value.

I agree with just special-casing this for now.

Aug 13 2019, 2:54 PM · Restricted Project
rjmccall added inline comments to D66121: Debug Info: Nest Objective-C property function decls inside their container..
Aug 13 2019, 2:29 PM · debug-info
rjmccall added inline comments to D66121: Debug Info: Nest Objective-C property function decls inside their container..
Aug 13 2019, 11:26 AM · debug-info
rjmccall added a comment to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.

I see. Is the deduction rule recursive or something, where a pointer to pointer is inferred to point to the same address space as the pointee? I still don't understand why pointers and references are handled differently here, instead of having the rule be "don't infer if the type is opaquely dependent or an auto placeholder".

Aug 13 2019, 11:23 AM

Aug 12 2019

rjmccall added inline comments to D66121: Debug Info: Nest Objective-C property function decls inside their container..
Aug 12 2019, 11:30 PM · debug-info
rjmccall added a comment to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.

Isn't the general rule for template argument deduction (which this devolves to) just to ignore top-level qualifiers? And then you can substitute in the substituted type and end up with a properly qualified type for the parameter / variable, and you can add extra qualifiers as necessary. Why are special rules for pointers and references required?

Aug 12 2019, 11:26 PM
rjmccall added a comment to D65994: Extended FPOptions with new attributes.

Oh, sorry, I confused several patches, then.

Aug 12 2019, 11:14 PM · Restricted Project
rjmccall added a comment to D66047: Do not call replaceAllUsesWith to upgrade calls to ARC runtime functions to intrinsic calls.

Ah, yes, if this isn't just working on intrinsic functions then that makes total sense.

Aug 12 2019, 11:42 AM · Restricted Project
rjmccall added a comment to D65665: Support for attributes on @class declarations.

Have you looked through the attributes that can be written on @interfaces and verified that they're all sensible to write on a @class? It's not hard to imagine that *some* of them should be diagnosed when added to a non-definition.

Aug 12 2019, 10:30 AM · Restricted Project
rjmccall accepted D47419: [SemaDeclCXX] Allow inheriting constructor declaration that specify a cv-qualified type.
Aug 12 2019, 10:30 AM · Restricted Project, Restricted Project
rjmccall accepted D66047: Do not call replaceAllUsesWith to upgrade calls to ARC runtime functions to intrinsic calls.

LGTM, although I'm not generally familiar with the upgrader code.

Aug 12 2019, 10:27 AM · Restricted Project