[PATCH] [ms-cxxabi] Mangle nullptr template arguments

Richard Smith richard at metafoo.co.uk
Mon Aug 5 09:19:11 PDT 2013


LGTM
On 5 Aug 2013 00:08, "David Majnemer" <david.majnemer at gmail.com> wrote:

> On Sun, Aug 4, 2013 at 11:41 PM, Richard Smith <richard at metafoo.co.uk>wrote:
>
>> On Sun, Aug 4, 2013 at 9:58 PM, David Majnemer <david.majnemer at gmail.com>wrote:
>>
>>> ================
>>> Comment at: lib/AST/MicrosoftMangle.cpp:894
>>> @@ +893,3 @@
>>> +  case TemplateArgument::NullPtr: {
>>> +    mangleIntegerLiteral(llvm::APSInt(/*BitWidth=*/64),
>>> /*IsBoolean=*/false);
>>> +    break;
>>> ----------------
>>> Richard Smith wrote:
>>> > Sending nullptr_t through the integer literal codepath seems
>>> unnecessary. All we really know here is that nullptr_t appears to be
>>> mangled as A@, so maybe just emit that directly.
>>> While we could do that, I think it makes the mangling scheme a bit more
>>> complicated semantically and it decentralizes the mechanism of choosing how
>>> to mangle zero-ish things.
>>>
>>> As an example: bool template arguments. True and false aren't given
>>> special mangling behavior. We "boolify" the integral value, treat the
>>> result as an integer and mangle **that** value.
>>
>>
>> That makes sense for bool, because it's an integer type, but there's
>> nothing really integery about nullptr. Plus the "64" here is
>> eyebrow-raising and ultimately irrelevant. (For Itanium, a null pointer
>> also happens to be mangled exactly as if it were an integer literal with
>> value 0 of the pointer type, but we have code to directly emit the mangling
>> there too.)
>>
>
> I find the argument behind nullptr's non-integralness sufficient to change
> direction, I've updated D1284.
>
> Thanks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130805/35d31bfa/attachment.html>


More information about the cfe-commits mailing list