[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220524004156.0000790e@garyguo.net>
Date: Tue, 24 May 2022 00:41:56 +0100
From: Gary Guo <gary@...yguo.net>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
Jarkko Sakkinen <jarkko@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...gle.com>,
Sven Van Asbroeck <thesven73@...il.com>
Subject: Re: [PATCH v7 06/25] rust: add `compiler_builtins` crate
On Mon, 23 May 2022 11:37:16 -0700
Nick Desaulniers <ndesaulniers@...gle.com> wrote:
> Also, I'm not sure my concern about explicit build failures for C code
> was ever addressed? We have a constant problem with `long long`
> division on ARCH=arm32 and ARCH=i386 in C code.
> https://lore.kernel.org/lkml/CAKwvOdk+A2PBdjSFVUhj4xyCGCKujtej1uPgywQgrKPiK2ksPw@mail.gmail.com/
>
> > +#[cfg(target_arch = "arm")]
> > +define_panicking_intrinsics!("`u64` division/modulo should not be
> > used", {
> > + __aeabi_uldivmod,
> > + __mulodi4,
> > +});
Starting in LLVM 14 (used in Rust 1.60+), __mulodi4 will no longer be
generated. So that can be removed.
As for __aeabi_uldivmod, is there any reason that it can't just be
defined in arch/arm/lib? There are quite a few __aeabi functions already
defined there.
The source of __aeabi_uldivmod in compiler-rt seems quite simple, just
delegating to __uldivmoddi4. I think just changing that to
div64_u64_rem should do the job?
https://android.googlesource.com/toolchain/compiler-rt/+/release_32/lib/arm/aeabi_uldivmod.S
- Gary
Powered by blists - more mailing lists