[Pkg-rust-maintainers] Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

[James Addison]

Followup-For: Bug #973414
X-Debbugs-Cc: fierelier at gmail.com

On Mon, 3 Apr 2023 23:07:35 +0200, Fierelier wrote:
> * In terms of confusion: I think using the Rust i586 toolchain, and
> building for i586 with Rust might be less confusing, because altering
> the i686 definitions for rustc will make it act differently compared
> to other platforms. People could compile code for i686 on Debian, get
> working code, but then if someone else does the same on another
> distro, the produced binary would not work on the same devices.

That's a fair point, yep; matching upstream behaviour is often the simplest and
most understandable approach.

It seems the choice is between using an upstream-compatible definition, or an
inter-toolchain-compatible definition (are there any other choices?  I did
notice use of per-extension feature flags in some build configurations. they
don't appear widely standardized though, or at least that's my initial sense).

> Although, I think changing the i686 definition down, like you did, is
> the most accurate way to achieve the goal, and is what I personally
> think should be mainline. If the accurate definition proves itself on
> Debian, it might find itself in mainline Rust, too, which would be
> awesome.

Thanks - and thank you for re-stating the intent of the patch. (I confusingly
wrote "my personal preference" instead of "my personal opinion" in a previous
comment)

I wouldn't want Debian's choice to be intended as a way to influence Rust's
upstream choices.  It'd be more a case of "who is comfortable using a divergent
definition of "i686" for longer before their respective communities call them
out on it" (in other words: each project can take their own path, and each
project can decide how to proceed, as they usually would).