- User Since
- Jan 18 2013, 11:30 AM (304 w, 2 d)
I don't think we should be reducing the number of call arguments we can support, sorry, even if 16K is a fairly absurd number that would probably trip stack overflow protections if you actually executed it. Let's try to keep it at least 64K-ish.
Fri, Nov 16
Hmm. This makes Optional<int> non-trivial, which is a serious semantic problem for certain uses of the type (e.g. putting it in a union); it's not just an optimization. Obviously those were unportable because of the #if, but we should really fix this. There's no way that GCC just generically miscompiles all partial specializations.
Thu, Nov 15
Wed, Nov 14
Oh, I see, sorry. Please rename these functions to make their purpose clear.
This should not be changing the actual @-encoding value. If we want to use the @-encoding in the symbol name, we can change it when naming the symbol, provided that \1 is not legal in the @encoding.
IIRC, abbreviations just silently don't take effect if the record doesn't conform; so things will appear to work, but the size on disk will be bigger.
Tue, Nov 13
I'm not worried about the mangler being re-used for multiple declarations, I'm worried about a global flag changing how we mangle all components of a type when we only mean to change it at the top level.
Seems reasonable to me.
Mon, Nov 12
Seems reasonable to me.
Fri, Nov 9
Thu, Nov 8
Wed, Nov 7
Tue, Nov 6
Mon, Nov 5
Okay, that's interesting. And that dynamic linking step includes fairly unrestricted linking of OpenCL code to other OpenCL code, rather than just e.g. loading a single block of OpenCL code that exports a small, fixed interface? If so, then I accept that you need symbol visibility.
I agree with Richard that I'm not sure what the point of supporting frontend visibility settings in OpenCL is. If you want the "everything is internal to the image" optimization, presumably you can just infer visibility on everything in a pass over the IR.
Sun, Nov 4
Sat, Nov 3
That looks a lot better, thanks. Did you check whether any other tests needed adjustment? That's not uncommon from this kind of desugaring change.
Pfft, if I'm going to be held responsible for my own work, I'm in a lot of trouble. :)
Changing how TemplateSpecializationType is declared in TypeNodes.def has way more implications than you're giving it credit for.
I'm just concerned about adding a great deal of complexity to mainline Clang in order to support a language that might still be in major flux and which I feel is likely to be forced to re-embrace qualifiers in the language model. Maybe this work should happen in a branch for awhile, at least for superficial things — patches to e.g. generalize things at the IRGen level to handle address spaces in various C++ language features would still be welcome, since those are likely to be useful across language modes.
Fri, Nov 2
That sounds more like this use of the mangler isn't manipulating the function type context correctly. But actually I think the problem is that it's ridiculous to assume that arbitrary local declarations have meaningful manglings. Why are we calling getStaticDeclName on a variable that's obviously not static?
Thu, Nov 1
- You would have an inconsistency in either case, since e.g. numeric + otherwise always returns the same type as its operands, but this would not.
True, but the CompoundAssignOperator already has that inconsistency with ComputationResultType.
Wed, Oct 31
Thanks. Still LGTM. :)
Seems reasonable to me.
Tue, Oct 30
Well, that's the old style, but we've been slowly moving to the camelCase style instead. Very, very slowly. I won't hold up your patch over it.
Thanks, and I agree with renaming the existing option.
That's interesting. If you think of a list-initialization of an aggregate as effectively defining an *ad hoc* constructor for it, then yes, we clearly ought to have access to protected destructors of base classes. And that aligns with the intuition that people make their destructors protected in order to prevent types from being constructed except as base sub-objects, which is still valid here. But at the same time, at a low level, we are directly accessing a protected destructor from a context that is not code actually defined in a subclass.
Mon, Oct 29
Sun, Oct 28
Fri, Oct 26
This should at least be named emitScalarConstant.
I don't suppose there's any chance you can just tell Khronos to fix their stuff. It's a little funny to be more conservative about keywords in C++ when the C++ committee is actually much more aggressive about adding keywords in the non-reserved space than C is.
So, three points:
Thu, Oct 25
Oops, sorry for the unedited comment; it's fixed on Phab.
Wed, Oct 24
Yeah, I agree that changing child order is problematic.
Tue, Oct 23