[PATCH] D123138: [demangler] Fix undocumented Local encoding

Iain Sandoe via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 6 04:58:38 PDT 2022


iains added a comment.

In D123138#3432417 <https://reviews.llvm.org/D123138#3432417>, @urnathan wrote:

> In D123138#3432207 <https://reviews.llvm.org/D123138#3432207>, @iains wrote:
>
>> just to clarify the intent for:
>>
>>   export module A;
>>   
>>   static int addone (int y) { return y + 1; }
>>   static int x = 5;
>>   
>>   export int addsix (int z) { return x + addone (z); }
>>
>> GCC mangles addone => `_ZW1AL6addonei`
>> and x as `_ZW1AL1x`
>>
>> clang mangles them as `_ZL6addonei` and `_ZL1x` respectively.
>>
>> Whilst this makes no practical difference (since the symbols are TU-local in either case) - I was expecting that decls in the purview of A would be attached to it (and thus mangled as such).   I guess I missed some subtlety.
>
> The ABI just specifies the mangling for cross-TU-visible symbols.  Different compilers may choose different manglings for internal-linkage symbols.
>
> That said, it seems I made different choices in GCC and Clang manglers, which isn't the best ($urnathan[GCC] != $urnathan[Clang]).  I guess if the elf-linkage on a template instantiation over some internal-linkage entity gets the wrong linkage, the GCC approach is better?

That would be my thinking too (also a little more helpful to poor souls who sometimes need to look at .ll and .s files).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123138/new/

https://reviews.llvm.org/D123138



More information about the llvm-commits mailing list