libiberty fails to demangle valid lambda kernel symbols

[BenWibking]

I seem to have hit an edge case in demangling. Most of my kernel names are demangled, but a few aren't, and I don't know why.

I've attached the full output. The function signatures are highly templated and very long (sorry). Maybe there is a length limitation hidden in the demangler?

iprof_full_names.txt

[BenWibking]

Codex diagnosis:

The exact issue is a demangler compatibility gap:

  - The names come from Clang’s __builtin_sycl_unique_stable_name.
  - They use Clang’s Itanium-style encoding for deeply nested, locally scoped SYCL lambdas, including Clang’s stable lambda numbering and substitution
    references such as S12_ and SW_.

  - LLVM’s demangler decodes the representative failing name completely.
  - GNU libiberty 2.41—the demangler used by this iprof build—rejects it and returns the original string.

  I placed the exact _ZTS... string into a temporary ELF symbol and compared both implementations:

  llvm-nm --demangle:
    typeinfo name for void amrex::launch<256, ...>::'lambda'(...)

  nm -C / c++filt:
    _ZTSZZN5amrex6launchILi256E...

  The important tail is:

  ENKUlRNSU_7handlerEE_clES12_EUlSW_E_

  LLVM correctly interprets this as nested closure types approximately equivalent to:

  [...](sycl::_V1::handler &) {
      [...](sycl::_V1::nd_item<1>) { ... };
  }

  S12_ and SW_ are back-references into the mangling’s substitution table. GNU libiberty loses or disagrees with Clang about that substitution state in
  these deeply nested local-name encodings. Removing an earlier qualifier can make libiberty accept the string, but produces an incorrect demangling
  because all subsequent substitutions then resolve differently. So this is not repairable by deleting or adding an E.

  Clang explicitly documents that SYCL stable names use Itanium mangling, stable lambda ordering, and are intended to be demanglable: Clang language
  [extensions](https://clang.llvm.org/docs/LanguageExtensions.html#builtin-sycl-unique-stable-name) (https://clang.llvm.org/docs/LanguageExtensions.html#builtin-sycl-unique-stable-name).

[BenWibking]

@TApplencourt Here is a complete standalone reproducer for the bug:
demangle-reproducer.tar.gz

[BenWibking]

It still fails with libiberty 2.46.0.

[TApplencourt]

Can reproduce. liberty upstream (https://github.com/gcc-mirror/gcc/tree/master/libiberty) doesn't work neither with

_ZTSZZN5amrex6launchILi256EZNS_6detail16ParallelFor_doitINS_10MLMGABCTagIdEEZNS_11ParallelForIS4_ZNKS_12MLCellLinOpTINS_8MultiFabEE7applyBCEiiRS7_NS_13LinOpEnumType6BCModeENSA_9StateModeEPKNS_10MLMGBndryTIS7_EEbEUliiiRKS4_E_EEvRKNS_9TagVectorIT_EERKT0_EUliiiiiSI_E_EEvSO_SR_EUlRKN4sycl3_V17nd_itemILi1EEEE_EEviNS_11gpuStream_tESR_ENKUlRNSU_7handlerEE_clES12_EUlSW_E_

Now the question if how we can package correctly llvm::demangle

[BenWibking]

It may be possible to use llvm-cxxfilt (https://llvm.org/docs/CommandGuide/llvm-cxxfilt.html#description):

$ llvm-cxxfilt _ZTSZZN5amrex6launchILi256EZNS_6detail16ParallelFor_doitINS_10MLMGABCTagIdEEZNS_11ParallelForIS4_ZNKS_12MLCellLinOpTINS_8MultiFabEE7applyBCEiiRS7_NS_13LinOpEnumType6BCModeENSA_9StateModeEPKNS_10MLMGBndryTIS7_EEbEUliiiRKS4_E_EEvRKNS_9TagVectorIT_EERKT0_EUliiiiiSI_E_EEvSO_SR_EUlRKN4sycl3_V17nd_itemILi1EEEE_EEviNS_11gpuStream_tESR_ENKUlRNSU_7handlerEE_clES12_EUlSW_E_
typeinfo name for void amrex::launch<256, void amrex::detail::ParallelFor_doit<amrex::MLMGABCTag<double>, void amrex::ParallelFor<amrex::MLMGABCTag<double>, amrex::MLCellLinOpT<amrex::MultiFab>::applyBC(int, int, amrex::MultiFab&, amrex::LinOpEnumType::BCMode, amrex::LinOpEnumType::StateMode, amrex::MLMGBndryT<amrex::MultiFab> const*, bool) const::'lambda'(int, int, int, amrex::MLMGABCTag<double> const&)>(amrex::TagVector<amrex::MLMGABCTag<double>> const&, amrex::MLCellLinOpT<amrex::MultiFab>::applyBC(int, int, amrex::MultiFab&, amrex::LinOpEnumType::BCMode, amrex::LinOpEnumType::StateMode, amrex::MLMGBndryT<amrex::MultiFab> const*, bool) const::'lambda'(int, int, int, amrex::MLMGABCTag<double> const&) const&)::'lambda'(int, int, int, int, int, amrex::MLMGABCTag<double> const&)>(amrex::TagVector<amrex::MLMGABCTag<double>> const&, amrex::MLCellLinOpT<amrex::MultiFab>::applyBC(int, int, amrex::MultiFab&, amrex::LinOpEnumType::BCMode, amrex::LinOpEnumType::StateMode, amrex::MLMGBndryT<amrex::MultiFab> const*, bool) const::'lambda'(int, int, int, amrex::MLMGABCTag<double> const&) const&)::'lambda'(sycl::_V1::nd_item<1> const&)>(int, amrex::gpuStream_t, amrex::MLCellLinOpT<amrex::MultiFab>::applyBC(int, int, amrex::MultiFab&, amrex::LinOpEnumType::BCMode, amrex::LinOpEnumType::StateMode, amrex::MLMGBndryT<amrex::MultiFab> const*, bool) const::'lambda'(int, int, int, amrex::MLMGABCTag<double> const&) const&)::'lambda'(sycl::_V1::handler&)::operator()(sycl::_V1::handler&) const::'lambda'(sycl::_V1::nd_item<1>)

[TApplencourt]

Smaller nested lambda

applenco@aurora-uan-0009:~/project/tmp> c++filt _ZTSZZ1XIEEUlNS_EE_EUlS_E_
_ZTSZZ1XIEEUlNS_EE_EUlS_E_
applenco@aurora-uan-0009:~/project/tmp> ~/project/tmp/test_demangle '_ZTSZZ1XIEEUlNS_EE_EUlS_E_'
typeinfo name for X<>::'lambda'(X)::'lambda'(X)

[TApplencourt]

Opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126623

[TApplencourt]

Hopefully

argonne-lcf/THAPI-spack#118
and
#523

Will fix this