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

[Tom Honermann via cfe-dev]

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?

$ cat t.h
inline int f() {
   return ^{
     static int slv;
     return slv++;
   }();
}

$ cat t1.cpp
#include "t.h"
int f1() {
   return f();
}

$ cat t2.cpp
#include "t.h"
int f2() {
   return f();
}

$ clang++ -c -std=c++11 -fblocks -O3 t1.cpp t2.cpp

$ nm t1.o
0000000000000000 T _Z2f1v
0000000000000000 V _ZZZ1fvEUb0_E3slv

$ nm t2.o
0000000000000000 T _Z2f2v
0000000000000000 V _ZZZ1fvEUb0_E3slv

Compiling with -O3 results in f() being inlined in f1() and f2() such 
that each TU resolves the reference to 'slv' without dispatch through f().

https://godbolt.org/g/w3rQMy

Granted, this is a fairly contrived example, so restoring the original 
ABI doesn't strike me as very likely to cause problems.

Tom.