__builtin_frame_address requires its argument to be a constant
expression which already implies that it cannot have undefined behavior.
However, we used EmitScalarExpr to emit the argument causing UBSan to
try to check for overflow.
Instead, use the constant expression emission system.
This fixes PR24256.
llvm-svn: 243206
option "-aarch64-reserve-x18".
This change is needed since backend options do not make it to the backend
when doing LTO and are not capable of changing the behavior of code-gen
passes on a per-function basis.
rdar://problem/21529937
Differential Revision: http://reviews.llvm.org/D11462
llvm-svn: 243185
Change `getOrCreateLimitedType()` to return a `DICompositeType` and
remove the casts from its callers. Inside, I've strengthened a `cast`
from `DICompositeTypeBase`, but the casts in the callers already prove
that this is safe. There should be no functionality change here.
llvm-svn: 243155
The outer nullability is transferred from the declaration to the implementation so including them is redundant.
The inner ones are not transferred so they are kept to match the exact types. When we transfer the inner ones as well
adding them in the implementation will become redundant and we should strip those as well.
rdar://21737451
llvm-svn: 243119
Address Richard Smith comments: remove the trailing seperator from the Arch
variable, implement six mingw_* trees under tools/clangtest/Driver/Inputs
and merge linux and Windows tests into a universal test that uses these trees.
llvm-svn: 243098
The flag allows users to specify that they do not want the object file
to have any implicit /defaultlib directives.
This fixes PR24236.
llvm-svn: 243097
We treated DependentSizedArrayTypes with the same element type but
differing size expressions as equivalently canonical. This would lead
to bizarre behavior during template instantiation.
This fixes PR24212.
llvm-svn: 243093
Generating available_externally vtables for optimizations purposes.
Unfortunatelly ItaniumABI doesn't guarantee that we will be able to
refer to virtual inline method by name.
But when we don't have any inline virtual methods, and key function is
not defined in this TU, we can generate that there will be vtable and
mark it as available_externally.
This is patch will help devirtualize better.
Differential Revision: http://reviews.llvm.org/D11441
llvm-svn: 243090
to consider the storage size of the vector instead of its
sizeof. In other words, ban <3 x int> to <4 x int> casts,
which produced invalid IR anyway.
Also, attempt to be a little more rigorous, or at least
explicit, about when enums are allowed in these casts.
rdar://21901132
llvm-svn: 243069
The catch keyword isn't really part of a region, so it's fairly
meaningless to extend into it. This was usually harmless, but it could
crash when catch blocks involved macros in strange ways.
llvm-svn: 243066
Large CFGs cause `checkForFunctionCall()` to overflow its stack. Break
the recursion by manually managing the call stack instead.
Patch by Vedant Kumar!
llvm-svn: 243039
Split out `hasRecursiveCallInPath()` from `checkForFunctionCall()` to
flatten nesting and clarify the code. This also simplifies a follow-up
patch that refactors the other logic in `checkForFunctionCall()`.
Patch by Vedant Kumar!
llvm-svn: 243038
Currently, for --rtlib=compiler-rt on GNU systems, we're assuming
that one has libgcc_s and libgcc_eh as low-level libraries, which
when used in conjunction with -lunwind or -lc++abi, breaks that
assumption.
My original fix was wrong, and this patch reverts it to prepare for
a new flag to choose the unwinder/C++ libraries. For the time being,
people can use "-lgcc_s -lgcc_eh" or "-lunwind -lc++abi" or any
combination they need explicitly.
llvm-svn: 243025
MSVC 2013 ships, as part of its STL implementation, a class named
'_Atomic'. This is unfortunate because this keyword is in conflict with
the C11 keyword with the same name. Our solution was to disable this
keyword when targeting MSVC 2013 and reenable it for 2015.
However, this makes it impossible for clang's headers to make use of
_Atomic. This is problematic in the case of libc++ as it makes heavy
use of this keyword.
Let the keywordness of _Atomic float under certain circumstances:
the body of a class named _Atomic, or a class with a base specifier
named _Atomic, will not have the keyword variant of _Atomic for the
duration of the class body. This is sufficient to allow us to correctly
handle _Atomic in the STL while permitting us to use _Atomic as a
keyword everywhere else.
Differential Revision: http://reviews.llvm.org/D11233
llvm-svn: 242970
Now clang should be able to use compiler-rt and libc++ on mingw.
Based on a patch by Martell Malone.
Differential Revision: http://reviews.llvm.org/D11237
llvm-svn: 242905
Summary:
Create diagnostic for function concept declaration which is not a
definition.
Create diagnostic for concept declaration which isn't in namespace
scope.
Create associated tests.
Reviewers: rsmith, faisalv, fraggamuffin, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11027
Patch by Nathan Wilson!
llvm-svn: 242899
more modules are added: visit modules depth-first rather than breadth-first.
The visitation is still (approximately) oldest-to-newest, and still guarantees
that a module is visited before anything it imports, so modules that are
imported by others sometimes need to jump to a later position in the visitation
order when more modules are loaded, but independent module trees don't
interfere with each other any more.
llvm-svn: 242863
Before we skipped that for virtual functions not fully qualified (r81507).
This commit basically reverts this to the older behaviour, which seems
more consistent. We now also correctly consider ill-formed calls to deleted
member functions, which were silently passed before in some cases.
The review contains the whole discussion.
PR: 20268
Differential Revision: http://reviews.llvm.org/D11334
llvm-svn: 242857
the identifier table. This is redundant, since the TU-scope lookups are also
serialized as part of the TU DeclContext, and wasteful in a number of ways. We
still emit the decls for PCH / preamble builds, since for those we want
identical results, not merely semantically equivalent ones.
llvm-svn: 242855
We ended up with the wrong predefine after the recent TargetParser shuffle, and
I accidentally solidified it with a test. This should fix it.
llvm-svn: 242841
Benjamin Kramer