D54301 and D54297 will resolve this issue

LGTM. Out of paranoia, I verified using compiler explorer that it's reliably const enough to use in a macro even at -O0 with an old clang.

I don't care how it's fixed, but I will commit this pretty soon if a broader fix isn't added. The linuxkpi fix should never have been committed without a fallback.

Bump compiler version to 19.1.0 since development versions may not
include __builtin_popcountg.

prefix functions with ipf_

Switch to checking for SIZEOF_INTCAP. The compiler will define it
if it implements __intcap_t.

These names aren't generic and I'd like to use them for copy{in,out} variants that explicitly preserve pointer provenance as part of the CHERI import (we currently use copy{in,out}cap in CheriBSD to preserved pointer provenance when pointers are implemented as CHERI capabilities, but think it's better to talk about pointers rather than capabilities which have too many meanings even within the tree.)

Clarify why _ALIGN* are obsolete and what should be used instead.

• Attempt to clarity _ALIGN's questionable interface
• Use __align_up (just wraps the builtin which has is supported on all compilers that support typeof() by a fallback).

Add an inline function to compute the misalignment. To it in nscache.h
rather than libc_private.h as that's also a private header and I don't
want this sort of thing to spread.

Seems good to me.

Spelling

Describe the types

Actually switch to a pattern

Switch to a pattern

Add some advice about (not) using __intcap_t

In D53819#1229955, @kib wrote:

And where is __intcap_t defined? Is it provided by some MD include, like machine/_types.h?

I do not remember seeing this MD define in the review series. If true, then should __intcap_t added before the use?

I don't feel super strongly about this, but I'm not entirely convinced we should be defining these from first principles. I believe that compilers we care about define __*_WIDTH__ macros we could use instead and things are likely to go very badly wrong if there's disagreement.

In D53817#1229561, @markj wrote:

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

In D53817#1229542, @kib wrote:

So may be do not expose ptraddr_t yet, until it is finalized? If they choose (slightly) different semantic, we would have a huge problem.

On CheriBSD we also include intcap_t and uintcap_t to be friendly, but we're trying to discourage the hybrid programming model so I'd like to stick with __ variants in FreeBSD.

In D53801#1229342, @kib wrote:

After thinking about this code some more, I realized that it probably should be removed altogether. Basically, it is there to allow to run newer binaries (rtld/libsys) on older (pre-AT_ renumbering) kernels. This was done in ~2019, and arguably outlived even the limited usefulness it had at the time of the commit.

Please add Effort: CHERI upstreaming to the commit message so we count this as part of that effort.