Hi Iain, > When generating thunks in the D front-end, they need not necesarily be > in the same compilation unit as the module where the target function is > declared. When this happens, don't make the thunk public. Later on > expand_thunk will be called with force_gimple_thunk=true, so the thunk > can never be made weak due to differing implementations between modules. > > Bootstrapped and tested on x86_64-linux-gnu, and committed to trunk. > > Regards > Iain. > --- > gcc/d/ChangeLog: > > PR d/92216 > * decl.cc (make_thunk): Don't set TREE_PUBLIC on thunks if the target > function is external to the current compilation. > > gcc/testsuite/ChangeLog: > > PR d/92216 > * gdc.dg/imports/pr92216.d: New. > * gdc.dg/pr92216.d: New test.
this new 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. Btw., I noticed that binutils 2.34 c++filt -s dlang cannot demangle those symbols. Is this expected? Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University