[Bug c/66970] Add __has_builtin() macro

[frankhb1989 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970

frankhb1989 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |frankhb1989 at gmail dot com

--- Comment #20 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #11)
> I hate that behaviour. Having to use !__is_identifier(__builtin_launder) is
> confusing (and not just to me, but to developers of LLVM's own libc++, who
> I've had to explain the problem to).
> 
> But consistency with Clang is probably more important than making
> __has_builtin behave sanely.

What if breaking that insane compatibility? How does it make things worse?

`__has_builtin` is expected to be OK even with false negative results (but
surely not false positive ones). Is there any real examples showing that
relying on something like `!__has_builtin(__builtin_offsetof)` necessary for
the needs in practice?

Note that there is already no warranty by the standard with the use of `__`,
and I don't ever find reasons that things like `int __builtin_abort = 0;`
should work besides the leaked implementation details. Such abuse seems not
documented at all. Even such use is eventually guaranteed to work, the extent
should be justified by `__is_identifier`, with nothing to do with the
`__builtin_` prefix.