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
