[PATCH] MIPS: Fix the GCC version check for `__multi3' workaround

[PATCH] MIPS: Fix the GCC version check for `__multi3' workaround

[Maciej W. Rozycki]

It was only GCC 10 that fixed a MIPS64r6 code generation issue with a 
`__multi3' libcall inefficiently produced to perform 64-bit widening 
multiplication while suitable machine instructions exist to do such a 
calculation.  The fix went in with GCC commit 48b2123f6336 ("re PR 
target/82981 (unnecessary __multi3 call for mips64r6 linux kernel)").

Adjust our code accordingly, removing build failures such as:

mips64-linux-ld: lib/math/div64.o: in function `mul_u64_add_u64_div_u64':
div64.c:(.text+0x84): undefined reference to `__multi3'

with the GCC versions affected.

Fixes: ebabcf17bcd7 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601140146.hMLODc6v-lkp@intel.com/
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Cc: stable@vger.kernel.org # v4.15+
---
 arch/mips/lib/multi3.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

linux-mips-multi3-gcc10.diff
Index: linux-macro/arch/mips/lib/multi3.c
===================================================================
--- linux-macro.orig/arch/mips/lib/multi3.c
+++ linux-macro/arch/mips/lib/multi3.c
@@ -4,12 +4,12 @@
 #include "libgcc.h"
 
 /*
- * GCC 7 & older can suboptimally generate __multi3 calls for mips64r6, so for
+ * GCC 9 & older can suboptimally generate __multi3 calls for mips64r6, so for
  * that specific case only we implement that intrinsic here.
  *
  * See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981
  */
-#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6) && (__GNUC__ < 8)
+#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6) && (__GNUC__ < 10)
 
 /* multiply 64-bit values, low 64-bits returned */
 static inline long long notrace dmulu(long long a, long long b)
@@ -51,4 +51,4 @@ ti_type notrace __multi3(ti_type a, ti_t
 }
 EXPORT_SYMBOL(__multi3);
 
-#endif /* 64BIT && CPU_MIPSR6 && GCC7 */
+#endif /* 64BIT && CPU_MIPSR6 && GCC9 */

Re: [PATCH] MIPS: Fix the GCC version check for `__multi3' workaround

[David Laight]

On Mon, 30 Mar 2026 02:54:09 +0100 (BST)
"Maciej W. Rozycki" <macro@orcam.me.uk> wrote:

> It was only GCC 10 that fixed a MIPS64r6 code generation issue with a 
> `__multi3' libcall inefficiently produced to perform 64-bit widening 
> multiplication while suitable machine instructions exist to do such a 
> calculation.  The fix went in with GCC commit 48b2123f6336 ("re PR 
> target/82981 (unnecessary __multi3 call for mips64r6 linux kernel)").
> 
> Adjust our code accordingly, removing build failures such as:
> 
> mips64-linux-ld: lib/math/div64.o: in function `mul_u64_add_u64_div_u64':
> div64.c:(.text+0x84): undefined reference to `__multi3'
> 
> with the GCC versions affected.
> 
> Fixes: ebabcf17bcd7 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601140146.hMLODc6v-lkp@intel.com/
> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
> Cc: stable@vger.kernel.org # v4.15+

Reviewed-by: David Laight <david.laight.linux@gmail.com.

Although it might be worth just deleting the version check.
__multi3 is unconditionally defined for sparc64 and that is a much
more complex function rather than the pretty trivial mips64 version.

> ---
>  arch/mips/lib/multi3.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> linux-mips-multi3-gcc10.diff
> Index: linux-macro/arch/mips/lib/multi3.c
> ===================================================================
> --- linux-macro.orig/arch/mips/lib/multi3.c
> +++ linux-macro/arch/mips/lib/multi3.c
> @@ -4,12 +4,12 @@
>  #include "libgcc.h"
>  
>  /*
> - * GCC 7 & older can suboptimally generate __multi3 calls for mips64r6, so for
> + * GCC 9 & older can suboptimally generate __multi3 calls for mips64r6, so for
>   * that specific case only we implement that intrinsic here.
>   *
>   * See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981
>   */
> -#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6) && (__GNUC__ < 8)
> +#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6) && (__GNUC__ < 10)
>  
>  /* multiply 64-bit values, low 64-bits returned */
>  static inline long long notrace dmulu(long long a, long long b)
> @@ -51,4 +51,4 @@ ti_type notrace __multi3(ti_type a, ti_t
>  }
>  EXPORT_SYMBOL(__multi3);
>  
> -#endif /* 64BIT && CPU_MIPSR6 && GCC7 */
> +#endif /* 64BIT && CPU_MIPSR6 && GCC9 */
> 

Re: [PATCH] MIPS: Fix the GCC version check for `__multi3' workaround

[Maciej W. Rozycki]

On Mon, 30 Mar 2026, David Laight wrote:

> Although it might be worth just deleting the version check.
> __multi3 is unconditionally defined for sparc64 and that is a much
> more complex function rather than the pretty trivial mips64 version.

 We want to catch invalid usage or we could just link with libgcc.a.

  Maciej

Re: [PATCH] MIPS: Fix the GCC version check for `__multi3' workaround

[David Laight]

On Mon, 30 Mar 2026 11:09:43 +0100 (BST)
"Maciej W. Rozycki" <macro@orcam.me.uk> wrote:

> On Mon, 30 Mar 2026, David Laight wrote:
> 
> > Although it might be worth just deleting the version check.
> > __multi3 is unconditionally defined for sparc64 and that is a much
> > more complex function rather than the pretty trivial mips64 version.  
> 
>  We want to catch invalid usage or we could just link with libgcc.a.

That would pull in all sorts of expensive functions - like divides.

One option would be have a 'u128 mul_u64_u64_u128(u64, u64)' function
that architectures could define, defaulting to (u128)a * b.

Similar definitions exist for mixed u64/u32 arithmetic on 32bit because
gcc tends to make a proverbial 'pig's breakfast' of compiling it.
(I've seen explicit multiplies by constant zeros that have been spilled
to stack!)

I recently improved/optimised the nolibc snprintf() code; that fell over
the same problem (on both mips64 and sparc64) doing the div/rem by 10
using multiply by reciprocal. I'm not sure how the kernel snprintf()
does the conversion - the entire function needs some TLC.
(That would probably speed up things like 'cat /proc/interrupts'.)

	David
 
> 
>   Maciej
>