I would probably keep this as a KASSERT(). pic_vector itself returns an int rather than a u_int. vector should match that, so I would say either explicitly check for vector < 0' in the KASSERT, or change pic_vector` and the various implementations of it to return a u_int in addition to changing vector. (Calling it pic_first_irq while at it might be even better)

security/isal-kmod is ok.

• Update to newer libcxx-gdbpy.

I have some other changes to libcxx-gdbpy I need to push to GitHub and update the hash in here again to add pretty printers for std::deque<> and std::stack<>.

I think the goal was to also be similar to the name used for the AHCI and NVMe device models which both use "ser" for this.

• Rebase.
• COMPAT_FREEBSD12 -> COMPAT_FREEBSD13.
• Reject negative 'index' and 'count'.

Whoops, sorry, this isn't NVMe. :)

@chuck, would you be able to test this easily?

I think this is fine, just one thought.

I'd be happy btw with fixing i386 to stop using alloca() rather than my GCC warning hack. I do wonder why we can't just use the normal save area though?

Not sure why this didn't auto close. I committed a version that folded in the changes to move 'type' into the switch structure.

I have no idea if this is needed or not TBH.

In D31942#720643, @imp wrote:

As an alternative, you could define __has_builtin(x) to 1 and suffer with a less precise error message should x not actually be supported.

The build fails with GCC on all architectures.

This is definitely a workaround, and I don't fully understand why the tail call messes up this way when using GCC.

Adding an atomic_inc() wrapper might be a cleaner way of fixing this.