[Bug c/66970] Add __has_builtin() macro

["egallager at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #8 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to felix from comment #7)
> Created attachment 42188 [details]
> Preliminary patch
> 
> Based on the already-existing __has_attribute() support, I've developed a
> patch implementing this feature. Attached. 
> 
> After some superficial testing (./cc1 -E), it seems to be working correctly.
> I don't really have the resources to run regression tests, so I didn't
> (although I think regressions would be unlikely). I also didn't write any
> new tests or documentation. (I noticed __has_attribute also doesn't seem to
> have much of either.)
> 
> 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. The former has been
> requested in PR 60512 and rejected; it may be reasonable to revisit the
> issue. 
> 
> However, if more such preprocessor, er, built-ins are desired, it may start
> becoming unwieldy to implement them the way I did in this patch; it involved
> some amount of copy-pasting.

Thank you for the patch! Please send it to the gcc-patches mailing list for
review: https://gcc.gnu.org/ml/gcc-patches/