Please supply parameter names for the .Fn arguments. Thus,
.Fn __poll_chk "struct pollfd *fds" [...]

This "the" is probably not needed...

This may be better as .Dv; I'd have to check.

... particularly if this "for" is replaced with "in".

comma after warning.

cannot, or must not?

While I could, it doesn't make much sense because these functions are not meant to be called, they only exist in underscored headers and will appear in bug reports.

I have to add symlinks for the real functions.

It was needed because I was later referring to the compiler flags.

Yes, this is a good change, Thanks!

cannot: we#error any attempt.

Start new sentences on new lines.

Start new sentences on new lines.

s/adds/add/

The purpose of this colon is not clear. Should the sentence just be split here?

This sentence conflicts a bit with the previous ones. Might be a typo where "do" should be "do not". Or the sentence needs to point out that this is an exception, possibly replacing "do appear visible" with just "are visible":

However, checker functions are visible when debugging or when reporting an

Replace this colon by splitting this sentence in two. Add a comma after "reason":

optimization mode.
For this reason, disabling optimizations also involves

Replace colon by splitting sentence in two.

s/only/only a/
s/of/of the/

I would suggest:

.Nm
was introduced in
.Fx 11.0.``

Can be simplified a bit:

Buffer overflows that are detected at compile time are reported by the compiler.
Otherwise, the checks are performed at runtime and produce an error message.

Um, conformant to what? Is this a warning that higher levels might cause false positives?

TBH, I preserved the language used by the author of the GCC implementation.
My understanding is that indeed it will produce false positives and we have seen one such case when building world on MIPS (and only on MIPS!?).

These checks should not be globally !clang, they should be a new macro that is something like __FORTIFY_WORKING_BUITLIN_OBJECT_SIZE. Clang 3.8 has some patches that look as if they will fix these, and I'd hate to have to go and replace all of these with a clang version check. There should be a single version check in cdefs.h

__bos is a horrible name for this. Please change it to __object_size (i.e. something descriptive) or just use the builtin directly.

Why not use __builtin_choose_expr here and make it call the real one where the compiler doesn't know the bounds?

__bos0 is an even more horrible macro name, as it both exposes details of the underlying implementation and simultaneously fails to provide readers with useful information about what it does.

While I'm complaining about poor naming, most of these _bos variables could also have human-friendly names (e.g. _ptr_size).

Why are we adding branch prediction to a compile-time constant?

As above, why predict a compile-time constant?

See also every other place where this is repeated.

Please move this to the definition of __bos() using __builtin_choose_expr.

Why not make this (and all other similar checks) a _Static_assert? We know at compile time that it will abort at run time, so tell the user at compile time that their code is broken.

mul_no_overflow is an identifier that is valid for user programs to use and so should not be used in a system header.

This function appears to duplicate the version in the header. Why does it exist?

Logic error. If we don't statically know the object size, then we skip the overflow checking. If there is an overflow, then we don't emit an error, we do exactly the same thing as if we'd not done the overflow checking.

All of these __predict_false() cases are going to make code slower if compiled with the system compiler (which, unconditionally, is setting this to __FORTIFY_UNKNOWN_SIZE).

Another logic error. If we don't know the size, then don't do overlap checks.

It would be more human-friendly to promote these to memmove with a warning.

This is overcomplicated logic. It should be:

if (bos != __FORTIFY_UNKNOWN_SIZE && (n > bos))
  __fortify_chk_fail("memchr: prevented read past end of buffer");
return (memchr(s, c, n));

These functions all look wrong. In the header wrappers, we're not trusting clang's __builtin_object_size, so we're eliding all of the checks, but then we're passing that value through unmodified to this function, which now does checks against it.

These functions should *never* be called with bos == __FORTIFY_UNKNOWN_SIZE and should have an assert to that effect.

I'm stopping individual reviews at this point, as every single function appears to reproduce the same logic errors.

Needs a comma after "Otherwise", because there is a pause there.

s/may/might/ ("may" for permission, "might" for possibility: "Yes, you may use my spare video card. It might not work any more, though.")