to create the special Neon vector types. These are intended to be used in
Clang's version of <arm_neon.h> to define special Neon vector types that will
be mangled according to ARM's ABI.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119301 91177308-0d34-0410-b5e6-96231b3b80d8
This is needed for Neon types when it is most natural to define them in terms
of a typedef. For example, Neon poly8_t is a typedef for "signed char", and
we want to define polynomial vectors as vectors of that typedef. Without this
change, the result will be a generic GCC-style vector. I think this is safe
for other vector types as well, but I would appreciate a review of this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119300 91177308-0d34-0410-b5e6-96231b3b80d8
one of the special Neon types. We'll check for invalid Neon vectors when
they are created, so there's no point in handling them when mangling.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119299 91177308-0d34-0410-b5e6-96231b3b80d8
certain internal type-checking procedures as well as for representing
certain implicitly-generated operations. Uses to follow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119289 91177308-0d34-0410-b5e6-96231b3b80d8
caching global code-completion results. In particular, don't perform
either operation the first time we parse, but do both after the first
reparse.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119285 91177308-0d34-0410-b5e6-96231b3b80d8
it is possible for the confluence block to only have a single predecessor due to calls to 'noreturn'
functions. Fixes assertion failure reported in PR 8619.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119284 91177308-0d34-0410-b5e6-96231b3b80d8
Clang currently uses a ridiculous amount of stack space when inlining
this function, which can lead to premature stack overflows.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119281 91177308-0d34-0410-b5e6-96231b3b80d8
casts the return value to something completely different. While we need better reasoning here,
we should definately not crash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119177 91177308-0d34-0410-b5e6-96231b3b80d8
Silence warning about -g not being used during linking. I couldn't find any
change in behavior in gcc liking when given -g. Please open another bug if
I missed something.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119166 91177308-0d34-0410-b5e6-96231b3b80d8
particular, we only add the implement object parameter type if only
one of the function templates is a non-static member function
template.
Moreover, since this DR differs from existing practice in C++98/03,
this commit implements the existing practice (which ignores the
first parameter of the function template that is not the non-static
member function template) in C++98/03 mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119145 91177308-0d34-0410-b5e6-96231b3b80d8
other platforms where the textual default of '/' isn't the system's root
directory. We should probably still make the textual default platform specific,
but this should avoid the particularly bad problem with the previous state: we
applied a sysroot of '/' to '/usr/local/google' which added
'//usr/local/include' to the windows header search path, a share on another
machine named 'usr'. Oops.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119131 91177308-0d34-0410-b5e6-96231b3b80d8
the Stmt* visitation in CursorVisitor to be
data-recursive.
Since AnnotationTokensWorker explicitly calls
CursorVisitor::VisitChildren(), it essentially
transforms the data-recursive algorithm in
CursorVisitor back into a non-data recursive one.
This is particularly bad because the data-recursive
algorithm uses more stack space per stack frame,
which can cause us to blow the stack in some cases.
"Fix" this by making the stack that AnnotationTokensWorker
runs in really huge. The real fix is to modify
AnnotationTokensWorker not to do the explicit
recursive call.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119047 91177308-0d34-0410-b5e6-96231b3b80d8
'LangOptionsBase' that default initializes all flags to 0. Now the ctor of LangOptions
only initializes the flags that might be non-zero (significantly simplifying things).
This also appeases Valgrind on Mac OS X, which no longer reports that one of the flags
may be uninitialized.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119045 91177308-0d34-0410-b5e6-96231b3b80d8
Elidable CXXConstructExpr should inhibit calling destructor for temporary
that is copied, not the one created. This is because eliding copy constructor
means that the object that was to be copied will be constructed directly in
memory the copy would be constructed in.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119044 91177308-0d34-0410-b5e6-96231b3b80d8
Return the result of a complex assignment with the original values,
not by performing a load from the l-value; this is the correct
semantics in C, although not in C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119037 91177308-0d34-0410-b5e6-96231b3b80d8
implicit conversions; the last batch was specific to promotions.
I think this is the full set we need. I do think dividing the cast
kinds into floating and integral is probably a good idea.
Annotate a *lot* more C casts with useful cast kinds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119036 91177308-0d34-0410-b5e6-96231b3b80d8
Ted Kremenek
John McCall
Bob Wilson
Zhanyong Wan
Douglas Gregor
Fariborz Jahanian
Rafael Espindola
Chandler Carruth
Zhongxing Xu
Chris Lattner
NAKAMURA Takumi