[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