The current implementation forces a compile-time 1/0 division, which
generates an undefined instruction (ud2 on x86) rather than a proper
runtime division-by-zero exception.

Change to trigger an actual div-by-0 exception at runtime, consistent
with other division operations. Use a non-1 dividend to prevent the
compiler from optimizing the division into a comparison.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
---

Change from v1 (http://lore.kernel.org/all/q2o7r916-5601-11pn-30pn-8n5ns6p079o7@onlyvoer.pbz):
- use OPTIMIZER_HIDE_VAR() in place of the open coded incantation.

diff --git a/lib/math/div64.c b/lib/math/div64.c
index 5faa29208bdb..bf77b9843175 100644
--- a/lib/math/div64.c
+++ b/lib/math/div64.c
@@ -212,12 +212,13 @@ u64 mul_u64_u64_div_u64(u64 a, u64 b, u64 c)
 
 #endif
 
-	/* make sure c is not zero, trigger exception otherwise */
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdiv-by-zero"
-	if (unlikely(c == 0))
-		return 1/0;
-#pragma GCC diagnostic pop
+	/* make sure c is not zero, trigger runtime exception otherwise */
+	if (unlikely(c == 0)) {
+		unsigned long zero = 0;
+
+		OPTIMIZER_HIDE_VAR(zero);
+		return ~0UL/zero;
+	}
 
 	int shift = __builtin_ctzll(c);

On Mon, 16 Jun 2025 15:22:44 -0400 (EDT)
Nicolas Pitre <npitre@baylibre.com> wrote:

> The current implementation forces a compile-time 1/0 division, which
> generates an undefined instruction (ud2 on x86) rather than a proper
> runtime division-by-zero exception.
> 
> Change to trigger an actual div-by-0 exception at runtime, consistent
> with other division operations. Use a non-1 dividend to prevent the
> compiler from optimizing the division into a comparison.

Given there is a definite 'plan' to avoid adding more BUG() to code
I'm not at all sure generating UB here is right at all.

I don't know the best solution though.
To my mind returning zero for divide by zero and ~0 for overflow is least
likely to cause real grief later on in the called code.

	David

> 
> Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
> ---
> 
> Change from v1 (http://lore.kernel.org/all/q2o7r916-5601-11pn-30pn-8n5ns6p079o7@onlyvoer.pbz):
> - use OPTIMIZER_HIDE_VAR() in place of the open coded incantation.
> 
> diff --git a/lib/math/div64.c b/lib/math/div64.c
> index 5faa29208bdb..bf77b9843175 100644
> --- a/lib/math/div64.c
> +++ b/lib/math/div64.c
> @@ -212,12 +212,13 @@ u64 mul_u64_u64_div_u64(u64 a, u64 b, u64 c)
>  
>  #endif
>  
> -	/* make sure c is not zero, trigger exception otherwise */
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wdiv-by-zero"
> -	if (unlikely(c == 0))
> -		return 1/0;
> -#pragma GCC diagnostic pop
> +	/* make sure c is not zero, trigger runtime exception otherwise */
> +	if (unlikely(c == 0)) {
> +		unsigned long zero = 0;
> +
> +		OPTIMIZER_HIDE_VAR(zero);
> +		return ~0UL/zero;
> +	}
>  
>  	int shift = __builtin_ctzll(c);
>

On Mon, 16 Jun 2025, David Laight wrote:

> On Mon, 16 Jun 2025 15:22:44 -0400 (EDT)
> Nicolas Pitre <npitre@baylibre.com> wrote:
> 
> > The current implementation forces a compile-time 1/0 division, which
> > generates an undefined instruction (ud2 on x86) rather than a proper
> > runtime division-by-zero exception.
> > 
> > Change to trigger an actual div-by-0 exception at runtime, consistent
> > with other division operations. Use a non-1 dividend to prevent the
> > compiler from optimizing the division into a comparison.
> 
> Given there is a definite 'plan' to avoid adding more BUG() to code
> I'm not at all sure generating UB here is right at all.
> 
> I don't know the best solution though.

The best solution is to be coherent with all the other divisions. They 
have well known behaviors, people are ready for them, debuggers are 
ready for them. If a given architecture doesn't trap and returns zero 
then with this patch we'll return zero too. If another arch raises an FP 
exception then we'll raise an FP exception. Coherency is the key.

> To my mind returning zero for divide by zero and ~0 for overflow is least
> likely to cause real grief later on in the called code.

Maybe. But that would be unexpected for some. Plenty of raw divisions 
without helper wrappers are out there. They won't all just produce 0.


Nicolas