https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94321
--- Comment #2 from Iain Buclaw <ibuclaw at gdcproject dot org> --- (In reply to Rainer Orth from comment #0) > As originally reported in > > https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542177.html > > [which didn't get Cc'ed to you due to the abominable header rewriting]: > > The new gdc.dg/pr92216.d testcase FAILs on 32-bit Solaris/SPARC and x86 (and, > I suppose, on every non-64-bit target): > > +FAIL: gdc.dg/pr92216.d -O0 scan-assembler > _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] > +FAIL: gdc.dg/pr92216.d -O0 -frelease scan-assembler > _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] > +FAIL: gdc.dg/pr92216.d -O0 -frelease -g scan-assembler > _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] > +FAIL: gdc.dg/pr92216.d -O0 -g scan-assembler > _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] > > Same at -O[1-3s]. While the 64-bit version contains the expected > > _DT16_D7imports7pr922161B8__mixin24getSMFZPv > > the 32-bit one has > > _DT8_D7imports7pr922161B8__mixin24getSMFZPv > > I can't tell for certain if it's enough to allow for those two variants > or if more is needed. > That discrepancy is the encoded this pointer offset. I didn't consider that this information was present when I added the test. > Btw., I noticed that binutils 2.34 c++filt -s dlang cannot demangle those > symbols. Is this expected? Yes, these thunk symbols are a non-standard extension.
