This patch implements __builtin_FUNCSIG intrinsic which returns the same string as __FUNCSIG__.

Fixes https://github.com/llvm/llvm-project/issues/58951
Differential Revision: https://reviews.llvm.org/D150183

Add '__builtin_FILE_NAME()', which expands to the filename because the
full path is not always needed. It corresponds to the '__FILE_NAME__'
predefined macro and is consistent with the other '__builin' functions
added for predefined macros.

Differential Revision: https://reviews.llvm.org/D144878

Fix __has_builtin to return 1 only if the requested target features
of a builtin are enabled by refactoring the code for checking
required target features of a builtin and use it in evaluation
of __has_builtin.

Reviewed by: Artem Belevich

Differential Revision: https://reviews.llvm.org/D125829

Summary:
Previously __has_builtin(__builtin_*) would return false for
__builtin_*s that we modeled as keywords rather than as functions
(because they take type arguments). With this patch, all builtins
that are called with function-call-like syntax return true from
__has_builtin (covering __builtin_* and also the __is_* and __has_* type
traits and the handful of similar builtins without such a prefix).

Update the documentation on __has_builtin and on type traits to match.
While doing this I noticed the type trait documentation was out of date
and incomplete; that's fixed here too.

Reviewers: aaron.ballman

Subscribers: jfb, kristina, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66100

llvm-svn: 368785

The source location builtins are implemented as keywords, but
__has_builtin should still report true for them.

This patch also fixes a test failure on systemz where the alignment
of string literals is 2 not 1.

llvm-svn: 361920

Summary:
This patch adds `__builtin_launder`, which is required to implement `std::launder`. Additionally GCC provides `__builtin_launder`, so thing brings Clang in-line with GCC.

I'm not exactly sure what magic `__builtin_launder` requires, but  based on previous discussions this patch applies a `@llvm.invariant.group.barrier`. As noted in previous discussions, this may not be enough to correctly handle vtables.

Reviewers: rnk, majnemer, rsmith

Reviewed By: rsmith

Subscribers: kristina, Romain-Geissler-1A, erichkeane, amharc, jroelofs, cfe-commits, Prazek

Differential Revision: https://reviews.llvm.org/D40218

llvm-svn: 349195

Summary:
The parsing logic has been separated out from the macro implementation logic, leading to a number of improvements:

* Gracefully handle unexpected/invalid tokens, too few, too many and nested parameters
* Provide consistent behaviour between all built-in feature-like macros
* Simplify the implementation of macro logic
* Fix __is_identifier to correctly return '0' for non-identifiers

Reviewers: doug.gregor, rsmith

Subscribers: rsmith, cfe-commits

Differential Revision: http://reviews.llvm.org/D17149

llvm-svn: 265381

We would CreateString on arbitrary garbage instead of just skipping to
the end of the builtin macro.  Eventually, this would cause us to crash
because we would end up replacing the contents of a character token with
a numeric literal.

This fixes PR21825.

llvm-svn: 224238

LLVM supports applying conversion instructions to vectors of the same number of
elements (fptrunc, fptosi, etc.) but there had been no way for a Clang user to
cause such instructions to be generated when using builtin vector types.

C-style casting on vectors is already defined in terms of bitcasts, and so
cannot be used for these conversions as well (without leading to a very
confusing set of semantics). As a result, this adds a __builtin_convertvector
intrinsic (patterned after the OpenCL __builtin_astype intrinsic). This is
intended to aid the creation of vector intrinsic headers that create generic IR
instead of target-dependent intrinsics (in other words, this is a generic
_mm_cvtepi32_ps). As noted in the documentation, the action of
__builtin_convertvector is defined in terms of the action of a C-style cast on
each vector element.

llvm-svn: 190915

__has_attribute, __has_extension, making them behave more akin to
conventional macros.

llvm-svn: 168268