• SrMordred (5/5) Apr 02 2018 (disclaimer: i'm a compiler noob)
• David Nadlinger (6/9) Apr 02 2018 In short, there is no way for the compiler to know whether they might be...
• SrMordred (2/13) Apr 02 2018 Nice, Thanks!

SrMordred <patric.dexheimer gmail.com> writes:

(disclaimer: i'm a compiler noob)

https://godbolt.org/g/9QS3j4

Why LDC keep unused assembly code like
'example.Int.__mixin2.toHash' or 'example.Int.__mixin2.opBinary'
on the binary?

"David Nadlinger" <code klickverbot.at> writes:

On 2 Apr 2018, at 17:36, SrMordred via digitalmars-d-ldc wrote:
 Why LDC keep unused assembly code like
 'example.Int.__mixin2.toHash' or 'example.Int.__mixin2.opBinary'
 on the binary?

In short, there is no way for the compiler to know whether they might be 
used from another module (object file).

They should disappear in the final executable on Linux (and I believe 
also Windows), though, if the linker does its job (--gc-sections).

  —David

SrMordred <patric.dexheimer gmail.com> writes:

On Monday, 2 April 2018 at 16:47:16 UTC, David Nadlinger wrote:
 On 2 Apr 2018, at 17:36, SrMordred via digitalmars-d-ldc wrote:
 Why LDC keep unused assembly code like
 'example.Int.__mixin2.toHash' or 
 'example.Int.__mixin2.opBinary'
 on the binary?

 In short, there is no way for the compiler to know whether they 
 might be used from another module (object file).

 They should disappear in the final executable on Linux (and I 
 believe also Windows), though, if the linker does its job 
 (--gc-sections).

  —David

Nice, Thanks!