- User Since
- Jan 18 2013, 11:30 AM (330 w, 3 d)
No, because hasCustomRR is set whenever the method implementation isn't the standard -[NSObject autorelease] implementation. In other words, this is just inlining the standard implementation when it's dynamically known that the dispatch would end up there anyway.
I don't know what you mean. Currently, if the callee tail-calls autorelease (and necessarily this has to be MRR code), we perform an ordinary message send of autorelease. It happens to be the case that the standard implementation of autorelease will allow the autorelease to be reclaimed, but nothing about that choice is in any way non-standard on the MRR side.
Thu, May 16
Oh, yes, that's correct, at least under base ObjC rules.
Thanks! Down to minor stuff now.
The assumption that these methods return the receiver is not true without additional semantic assumptions about these methods, so the current behavior of unconditionally turning [x autorelease] into objc_autorelease(x), x seems quite broken.
Fri, May 10
Thu, May 9
Wed, May 8
Tue, May 7
All of the IRGen changes in this patch are unnecessary according to the model we've worked out, right? The fix is just to mark the destructor as still used when we're constructing an array.
Mon, May 6
Fri, May 3
The flip side of that argument is that (1) there aren't very many users right now and (2) it's much easier to start conservative and then weaken the rule than it will be to strengthen it later. It really isn't acceptable to just turn off access/use-checking for the destructor, so if we get trapped by the choice we make here, we'll end up having to either leak or call std::terminate.
That's only true for subobjects of an enclosing aggregate before that aggregate's initialization is complete though, right? So it doesn't seem like that much of an inconsistency, just mimicking what we would be doing if an exception was thrown in, say, the body of the ctor before the object's initialization is completed.
Conceptually yes, but formally no. The standard *could* write this rule as "all currently-initialized subobjects must be separately destroyed when an exception aborts initialization of the containing aggregate, including constructor bodies and aggregate initialization", but it doesn't actually do so; instead it has specific rules covering the behavior when an exception is thrown out of the body of a constructor, and those rules simply do not apply to aggregate initialization.
Right, I was just trying to draw an analogy. Can you be more specific about the inconsistency you mentioned above? What objects with static storage duration have to be destroyed when an exception is thrown? Just subobjects of static aggregates that had their initialization aborted by an exception? If so, that obviously doesn't seem inconsistent.
Thu, May 2
I think it would be more reasonable to just change getDeclLanguageLinkage to check for a kernel function.
Wed, May 1
Okay. This seems reasonable to me, then.
Tue, Apr 30
@chandlerc, I hate to do this to you, but licensing question.
Hmm. You know, there's another case where the destructor can be called even for a non-array: if constructing the object requires a temporary, I believe an exception thrown from that temporary's destructor is supposed to go back and destroy the variable. (This is, sadly, not entirely clear under the standard since the object is not automatic.) Now, Clang does not actually get this correct — we abort the construction, but we don't destroy the variable — but (1) we should fix that someday and (2) in the meantime, we shouldn't implement something which will be a problem when we go to fix that.
Okay. So it sounds like this should either be a device-only rule, with no warning in mixed-mode languages like CUDA, or we should take a different approach.
Presumably a similar rule would apply to thread-locals if you supported them.
I don't think the implication is supposed to be that padding is zero-initialized or not depending on where in the aggregate it appears, but it doesn't really matter, I don't think we're arguing about the goal of this patch.
In Swift we basically shove *everything* through our corresponding linkage-entity structure, so I'm not opposed to the basic idea.
IIRC, C says *members* are initialized as if they were in static storage, which might mean that their interior padding should be zeroed, but I don't think says anything about the padding in the enclosing aggregate. But I think zero-initializing padding is probably the right thing to do in general under this flag.
Sat, Apr 27
It seems to fine just forbid hidden. Again, I suspect other targets do not care because they are not using a standard dynamic loader to load the code containing kernel functions.
Fri, Apr 26
I believe at least one of the goals of nodestroy is to allow the type to potentially not provide a destructor at all, so if we're going to implicitly require the destructor anyway in certain situations, we should clearly document that, and we should be aware that we may be making the attribute less useful.
Thu, Apr 25
Are you sure these are the right semantics for nodestroy? I think there's a reasonable argument that we should not destroy previous elements of a nodestroy array just because an element constructor throws. It's basically academic for true globals because the exception will terminate the process anyway, and even for thread_locals and static locals (where I believe the exception is theoretically recoverable) it's at least arguable that we should either decline to destroy (possibly causing leaks) or simply call std::terminate.
I do not think the ObjC version of this diagnostic is useful as it's been explained here, and I would strongly recommend just not including such a warning for the time being.
Sorry, yes, I meant in Objective-C methods, of course, not unconditionally even in C-like code whenever Objective-C is enabled.
Yeah, I tend to think we should just suppress this unconditionally in Objective-C.
Wed, Apr 24
Yeah, that seems like a missing warning.
Tue, Apr 23
Yeah, that's fine.
I suspect that other OpenCL and CUDA implementations don't care at all about symbol visibility for device-side code generation, and giving kernel functions default visibility seems like the right thing to do for the (relatively few) things at the AST level that are sensitive to that, like template visibility. Would you mind reaching out to other implementors about that?
Shouldn't it be an error if the user tries to give it hidden visibility?
It seems reasonable to me for target hooks to run after global hooks, but can I ask why AMDGPU specifically relies on this?
Apr 19 2019
I suspect Darwin also doesn't want to take this. We care very little about 32-bit Intel, and part of caring very little is not wanting to spend any effort dealing with the ramifications of ABI breaks. That would apply both to the rule in general and to the vector rule specifically. @dexonsmith, agreed?
Apr 18 2019
Apr 17 2019
Alright, this seems reasonable to me.
Apr 16 2019
Apr 11 2019
Hmm. Does this never impact code that's just using a locally-defined type within its scope? I guess if ADL is involved, unqualified lookup must have reached the scope of the innermost namespace, and so it would be searching that namespace anyway.
Should we have a special has_feature test to check that this attribute is allowed on implementations? We've done that in the past when expanding the set of subjects for an attribute. But that's not necessary if we haven't made this attribute part of a public Xcode release yet, because then the attribute is just understood to always apply to implementations; I can't remember when exactly this was added and what releases it's made it into.
Apr 10 2019
Committed as r358132.
Committed as r358115.