https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
--- Comment #12 from Eric Gallager <egallager at gcc dot gnu.org> --- (In reply to Jonathan Wakely from comment #11) > (In reply to felix from comment #7) > > I made the feature closely mimic The Other Compiler's behaviour: only > > function built-ins are recognised. This includes generic functions like > > __builtin_add_overflow and C library functions specially handled by the > > front-end like printf (unless -fno-builtin is used), but excludes types like > > __builtin_va_list and function-like constructs (implemented as keywords) > > like __builtin_offsetof and __builtin_types_compatible_p. This is not so > > much of a problem for them, since they also provide __has_feature(), > > __has_extension() and __is_identifier() macros. > > 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. maybe have a separate __sane_has_builtin? That way __has_builtin could still be compatible with clang, but there'd also be a sane alternative
