[cfe-dev] Invalid mangled names emitted for local types declared in Apple Block expressions used in non-static data member initializers

[Richard Smith via cfe-dev]

On 6 September 2017 at 20:27, John McCall via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> > On Sep 6, 2017, at 11:00 PM, Tom Honermann <
> Thomas.Honermann at synopsys.com> wrote:
> > On 9/6/2017 7:13 PM, John McCall wrote:
> >>
> >>> On Sep 6, 2017, at 5:50 PM, Richard Smith <richard at metafoo.co.uk
> >>>    The mangled name generated for the function template specialization
> >>>    instantiated for the local enum type 'E' uses a
> >>>    <pointer-to-member-type>
> >>>    production [1] (as signified by 'M'),
> >>>
> >>>
> >>> I believe you're mistaken. This is not a context in which a <type>
> >>> production can appear. That's a <data-member-prefix>:
> >>>
> >>> http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.
> data-member-prefix
> >
> > Ah, so it is.  Thanks for the correction.
> >
> >>> This behavior looks correct to me, except that I'm surprised that this
> >>> block is numbered as Ub0_ instead of Ub_. Looks like we have an
> >>> off-by-one error here, introduced in r214699 while fixing a different
> >>> off-by-one error.
> >>>
> >>> John: should we restore the pre-r214699 ABI, or would you prefer that
> >>> we just accept the new mangling as our ABI now?
> >>
> >> Nothing about blocks ever has identity across translation units, so
> >> there's no harm in fixing the bug and restoring the original ABI to
> >> start counting at b_.
> >
> > That doesn't seem right to me.  For example, aren't static local
> > variables declared within block expressions in inline functions required
> > to match across TUs?
>
> Ah, yes, you're right; I was thinking of the data directly associated with
> the block
> without considering its contents.
>
> > Granted, this is a fairly contrived example, so restoring the original
> > ABI doesn't strike me as very likely to cause problems.
>
> Yeah, I think it's better to just fix the bug.  I'm not too worried about
> this level of contrivance.
>

OK, done in r312700.


> John.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170906/5b5c0ec4/attachment.html>