On Fri, Apr 24, 2026 at 06:57:12AM -0500, Segher Boessenkool wrote: > On Fri, Apr 24, 2026 at 06:54:05AM -0500, Segher Boessenkool wrote: > > Hi! > > > > On Fri, Apr 24, 2026 at 11:17:40AM +0530, Mukesh Kumar Chaurasiya (IBM) > > wrote: > > > The core crate currently depends on these two functions for i64/u64/ > > > i128/u128/core::time::Duration formatting, but we shouldn’t use that in > > > the kernel so let’s panic if they are ever called. > > > > > > This doesn’t yet fix drm_panic_qr.rs, which also uses __udivdi3 when > > > CONFIG_CC_OPTIMIZE_FOR_SIZE=y, but at least makes the rest of the kernel > > > build on PPC32. > > > > GCC uses calls to functions like even __addsi3 whenever the (sub-)target > > does not implement some RTL, doesn't have a define_insn and the like for > > it. When you write a new port you only *have* to implement a very few > > things, the rest is done in libgcc (you might still have to write some > > of that for your target, no free lunch etc.) > > > > 32-bit PowerPC has no instructions for 64-bit divisions, nor > > instructions that help implementing it in software. It still very often > > helps to hand-write machine code for it, it very easily can usually be > > more than twice as fast for example (for example if the divisor is less > > than half a word big, the common case -- it can be made tens of times > > faster then). > > > > There can be many reasons why a GCC backend decides to call a libgcc > > routine. For __udivdi3 on -m32 rs6000 you'll be good AFAICS :-) > > (but poisoning functions like you do is a terrible idea in general!) > > Whoopsie, I forgot to mention: > > Approved for trunk.
Ugh, for some reason I thought this is a GCC patch :-( Segher
