These hexagon builtins incorrectly created aliases in the global
namespace which can (and in at least one case, did) conflict
with symbols defined by other programs.
This should address the issue reported as https://github.com/rust-lang/rust/issues/129823:
Compiling compiler_builtins v0.1.123
Compiling core v0.0.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
Compiling rustc-std-workspace-core v1.99.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
Compiling byteorder v1.5.0
Compiling zerocopy v0.7.34
error: symbol 'fma' is already defined
error: could not compile `compiler_builtins` (lib) due to 1 previous error
Also: some of the symbols defined were not just aliases, so those are
now qualified with `__hexagon_`. The compiler does not yet emit calls
to these particular ones, but if/when it does, it can use the new names.
This fixes such as (https://github.com/rust-lang/rust/issues/128386)
where, our implementation is being used on systems where there is
already `math` library and its more performant and accurate.
So with this change, linux will go back to the previous behavior and not
include these functions, windows and apple were generally not affected.
Looking at the targets we have builtin now in rust, everything else is
probably good to have the math symbols.
> A note on the above, the `hermit` os uses `libm` directly for itself,
> but I think its Ok to keep providing math in `compiler_builtin` for it,
> its technically the same implementation either from `compiler_builtin`
> or `hermit-builtins`.
Signed-off-by: Amjad Alsharafi <26300843+Amjad50@users.noreply.github.com>
There were some issues regarding windows and apple platform, we were
exporting symbols that are already provided by the compiler but weren't
marked as `weak` which resulted in conflicted symbols in the linking
process.
Initially, we didn't add `weak` because we thought it is not supported
on windows and apple platforms, but it looks like its only not supported
on windows-gnu platforms
Signed-off-by: Amjad Alsharafi <26300843+Amjad50@users.noreply.github.com>
Make the following changes:
- Add `rerun-if-changed` to the new `configure.rs`, it seems this was
causing incorrect caching.
- Change from matching `i686` to `x86`. The target triple starts with
`i686` so that is what we were checking before, but the architecture
is `x86`. This change should have been made when we added `struct
Target`, update it now instead.
Replace `public_test_dep!` by placing optionally public items into new
modules, then controlling what is exported with the `public-test-deps`
feature.
This is nicer for automatic formatting and diagnostics.
Since there are more platforms that do not have symbols present, we need
to use `rustc_apfloat` for more conversion tests. Make use of the
fallback like other tests, and refactor so each test gets its own
function.
Previously we were testing both apfloat and system conversion methods
when possible. This changes to only test one or the other, depending on
whether or not the system version is available. This seems reasonable
because it is consistent with all other tests, but we should consider
updating all tests to check both at some point.
This also includes an adjustment of PowerPC configuration to account for
the linking errors at [1].
[1]: https://github.com/rust-lang/compiler-builtins/issues/655
