Sounds like it might be connected to mixed SIMD (8 elements) + normal (last element) code. @seiko2plus any thoughts?

The reason will be that the simd operation fills up the a partial vector with ones to avoid exactly this issue, but 1/1e-309 overflows to inf.

Not sure what can actually be done to have partial loads there if we really worry about this, filling with NaN would be safe w.r.t. FPEs, if it doesn't stall performance for some reason.

EDIT: If NaN doesn't work (generally), the only alternative would be to ensure the divisor is 1, while currently we ensure the dividend is for a / scalar (scalar would need to be 1 padded not a)

The reason will be that the simd operation fills up the a partial vector with ones to avoid exactly this issue, but 1/1e-309 overflows to inf.

Yes that main reason, why handling remaining lanes for such basic operation via manual SIMD is important to avoid unexpected compiler optimization behavior that may lead to raise FP errors, mainly wide versions CLANG once sniffing a clear contiguous path.

Not sure what can actually be done to have partial loads there if we really worry about this, filling with NaN would be safe w.r.t. FPEs

Filling the remaining lanes of the vector divisor with ones is what actually matters to avoid division by zero FPe while the dividend nan or zero should be okay.

if it doesn't stall performance for some reason.

It doesn't affect the performance even scalarising the remains lanes will be okay since there's another loop that handles the full vectors load and store.

I think the following patch can fix this issue:

diff --git a/numpy/_core/src/umath/loops_arithm_fp.dispatch.c.src b/numpy/_core/src/umath/loops_arithm_fp.dispatch.c.src
index 30111258d6..4f083a5efa 100644
--- a/numpy/_core/src/umath/loops_arithm_fp.dispatch.c.src
+++ b/numpy/_core/src/umath/loops_arithm_fp.dispatch.c.src
@@ -138,7 +138,7 @@ NPY_NO_EXPORT void NPY_CPU_DISPATCH_CURFX(@TYPE@_@kind@)
                 npyv_store_@sfx@((@type@*)(dst + vstep), r1);
             }
             for (; len > 0; len -= hstep, src0 += vstep, dst += vstep) {
-            #if @is_div@ || @is_mul@
+            #if @is_mul@
                 npyv_@sfx@ a = npyv_load_till_@sfx@((const @type@*)src0, len, 1.0@c@);
             #else
                 npyv_@sfx@ a = npyv_load_tillz_@sfx@((const @type@*)src0, len);

even scalarising the remains lanes

Right, maybe that is the sane solution. Padding with 0 isn't quite right either because 0 / 0 is different from nonzero / 0: FPE will be "invalid value" vs. "overflow".
Padding with NaN should work for everything (never triggers FPE, except comparisons need care). But its not nice if NaNs might stall things in some other way.

Right, maybe that is the sane solution.

Yes but may open the door for compiler bugs likely FP error divide-by-zero as I mentioned.

different from nonzero / 0: FPE will be "invalid value" vs. "overflow".

Agrees, I think you mean it will lead to raising two separate exceptions invalid-value and divide-by-zero rather than only "divide-by-zero".

Padding with NaN

Looks practical solution to me, #25129 apply it.

But its not nice if NaNs might stall things in some other way.

The value that is used within the padded vector isn't generalized and should always defined based on the nature of the operation we deal with.

Thanks everyone!

This is fixed in 1.26.3 and later.