I’m not sure if this is the same case, but there’s at least one instance of this “bug” where llvm-undname is correct and undname is wrong. See the tests, i even left a comment about it in the test file. If this is the same thing, we should close this one since I believe the bug to be in undname.

I'm willing to believe it's an undname bug :-) The wine implementation of _unDName has it too fwiw.

I tried finding the test case you mention but failed.

...aha, but here's a from-source repro that shows you're right:

$ cat test.cc
struct S {};

struct T {
static const S* s_;

const S* s();
void set(const S* s);
};

const S* T::s() { return s_; }
void T::set(const S* s) { s_ = s; }

$ third_party/llvm-build/Release+Asserts/bin/clang-cl /c test.cc /Fa -Xclang -emit-llvm 2&>1 > /dev/null ; cat test.asm | grep s_
@"?s_@T@@2PEBUS@@eb" = external dso_local global %struct.S*, align 8
%0 = load %struct.S*, %struct.S** @"?s_@T@@2PEBUS@@eb", align 8
store %struct.S* %0, %struct.S** @"?s_@T@@2PEBUS@@eb", align 8

$ demumble '?s_@T@@2PEBUS@@eb' # currently uses wine _unDName()
public: static struct S const * __ptr64 const _ptr64 T::s

$ bin/llvm-undname '?s_@T@@2PEBUS@@eb'
?s_@T@@2PEBUS@@eb
public: static struct S const *T::s_