duplicated intrinsic implementations linked into libstd

[klensy]

duplicated intrinsic implementations linked into libstd, for example 1.73.0-nightly (da6b55cc5 2023-07-17). checked on x86_64-unknown-linux-gnu and x86_64-pc-windows-msvc.

running cargo expand will show, for example, that __adddf3 will be exported via 2 paths:
compiler_builtins::float::add::__adddf3 and
compiler_builtins::float::add::__adddf3::__adddf3
maybe it's the reason?

        pub extern "C" fn __adddf3(a: f64, b: f64) -> f64 {
            add(a, b)
        }
        pub mod __adddf3 {
            #[no_mangle]
            pub extern "C" fn __adddf3(a: f64, b: f64) -> f64 {
                super::__adddf3(a, b)
            }
        }

There can be few cases:

1. think function + implementation: for example __adddf3, where thunk (compiler_builtins::float::add::__adddf3::__adddf3) function is just jump to actual implementation compiler_builtins::float::add::__adddf3
2. 2 copies of the same implementation, for example __ashldi3
3. 2 different implementations (in asm representation), for example __divmodti4

[bjorn3]

The non-#[no_mangle] version isn't used by the compiler. It is only exported for testing purposes.

[klensy]

Should it be hidden by some feature to not to pollute stdlib?

[bjorn3]

If it is statically linked into a cdylib, staticlib or executable, the linker will omit it anyway as it is never used. Only for libstd.so would it include it, but libstd.so isn't optimized for size anyway. I guess you could attempt to hide it if it isn't too much effort, but it may not be worth the effort.

[Amanieu]

These could be put behind a feature flag which is only enabled when running tests.