| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
the balance between expected behavior and compatibility with the gdb
testsuite.
(GDB gets confused if we break an expression into multiple debug
stmts so we enable this behavior only for inlined functions. For the
full experience people can still use -gcolumn-info.)
llvm-svn: 177164
|
| |
|
|
|
|
|
|
| |
the requirements on the ARC optimizer.
rdar://13407451
llvm-svn: 176924
|
| |
|
|
|
|
|
|
|
| |
differentiate multiple inlined call sites on the same line
in the debug info.
Fixes rdar://problem/13036237
llvm-svn: 176895
|
| |
|
|
| |
llvm-svn: 176767
|
| |
|
|
|
|
|
|
| |
MaxAtomicPromoteWidth. Fix a ton of terrible bugs with
_Atomic types and (non-intrinsic-mediated) loads and stores
thereto.
llvm-svn: 176658
|
| |
|
|
| |
llvm-svn: 176657
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distinguishes between all of these
cases.
Also, normalize the API for loading and storing complexes.
I'm working on a larger patch and wanted to pull these
changes out, but it would have be annoying to detangle
them from each other.
llvm-svn: 176656
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
llvm-svn: 176286
|
| |
|
|
|
|
| |
array type.
llvm-svn: 175982
|
| |
|
|
|
|
| |
really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information.
llvm-svn: 175949
|
| |
|
|
|
|
|
| |
base-to-derived casts have undefined behavior if the object is not actually an
instance of the derived type.
llvm-svn: 175078
|
| |
|
|
| |
llvm-svn: 174257
|
| |
|
|
|
|
|
|
| |
Several places were still treating the Attribute object as respresenting
multiple attributes. Those places now use the AttributeSet to represent
multiple attributes.
llvm-svn: 174004
|
| |
|
|
|
|
| |
This is required to use them in TableGen.
llvm-svn: 173924
|
| |
|
|
|
|
|
|
|
|
|
| |
implementation; this is much more inline with the original implementation
(i.e., pre-ubsan) and does not require run-time library support.
The trapping implementation can be invoked using either '-fcatch-undefined-behavior'
or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter
being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed.
llvm-svn: 173848
|
| |
|
|
|
|
| |
OpenCL restrictions (OpenCL 1.2 spec 6.9)
llvm-svn: 172973
|
| |
|
|
| |
llvm-svn: 172808
|
| |
|
|
|
|
| |
Cast arithmetic results to avoid comparison of an unsigned to an int.
llvm-svn: 172570
|
| |
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
| |
|
|
|
|
| |
PR14825!
llvm-svn: 172031
|
| |
|
|
| |
llvm-svn: 171947
|
| |
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are visiting the extern declaration of 'i' in
static int i = 99;
int foo() {
extern int i;
return i;
}
We should not try to handle it as if it was an function static. That is, we
must consider the written storage class.
Fixing this then exposes that the assert in EmitGlobalVarDeclLValue and the
if leading to its call are not completely accurate. They were passing before
because the second decl was marked as having external storage. I changed them
to check the linkage, which I find easier to understand.
Last but not least, there is something strange going on with cuda and opencl.
My guess is that the linkage computation for these languages needs to be
audited, but I didn't want to change that in this patch so I just updated
the storage classes to keep the current behavior.
Thanks to Reed Kotler for reporting this.
llvm-svn: 170827
|
| |
|
|
| |
llvm-svn: 170722
|
| |
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
| |
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
| |
|
|
|
|
| |
of assignment to a bool bitfield. PR14638.
llvm-svn: 170480
|
| |
|
|
| |
llvm-svn: 170461
|
| |
|
|
| |
llvm-svn: 170403
|
| |
|
|
|
|
| |
to an object outside its lifetime does not have undefined behavior.
llvm-svn: 170387
|
| |
|
|
|
|
|
| |
Results in better block placement that helps close the
performance gap when making ubsan checks recoverable.
llvm-svn: 170263
|
| |
|
|
|
|
|
| |
bit-patterns which are not valid values for enumerated or boolean types.
These checks are the ubsan analogue of !range metadata.
llvm-svn: 170108
|
| |
|
|
| |
llvm-svn: 170100
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were emitting calls to blocks as if all arguments were
required --- i.e. with signature (A,B,C,D,...) rather than
(A,B,...). This patch fixes that and accounts for the
implicit block-context argument as a required argument.
In addition, this patch changes the function type under which
we call unprototyped functions on platforms like x86-64 that
guarantee compatibility of variadic functions with unprototyped
function types; previously we would always call such functions
under the LLVM type T (...)*, but now we will call them under
the type T (A,B,C,D,...)*. This last change should have no
material effect except for making the type conventions more
explicit; it was a side-effect of the most convenient implementation.
llvm-svn: 169588
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generally support the C++11 memory model requirements for bitfield
accesses by relying more heavily on LLVM's memory model.
The primary change this introduces is to move from a manually aligned
and strided access pattern across the bits of the bitfield to a much
simpler lump access of all bits in the bitfield followed by math to
extract the bits relevant for the particular field.
This simplifies the code significantly, but relies on LLVM to
intelligently lowering these integers.
I have tested LLVM's lowering both synthetically and in benchmarks. The
lowering appears to be functional, and there are no really significant
performance regressions. Different code patterns accessing bitfields
will vary in how this impacts them. The only real regressions I'm seeing
are a few patterns where the LLVM code generation for loads that feed
directly into a mask operation don't take advantage of the x86 ability
to do a smaller load and a cheap zero-extension. This doesn't regress
any benchmark in the nightly test suite on my box past the noise
threshold, but my box is quite noisy. I'll be watching the LNT numbers,
and will look into further improvements to the LLVM lowering as needed.
llvm-svn: 169489
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
| |
|
|
|
|
| |
after its lifetime has ended!
llvm-svn: 169170
|
| |
|
|
| |
llvm-svn: 169114
|
| |
|
|
| |
llvm-svn: 169041
|
| |
|
|
|
|
| |
in a logical operator.
llvm-svn: 169037
|
| |
|
|
|
|
|
|
|
|
|
| |
objc_loadWeak. This retains and autorelease the weakly-refereced
object. This hidden autorelease sometimes makes __weak variable alive even
after the weak reference is erased, because the object is still referenced
by an autorelease pool. This patch overcomes this behavior by loading a
weak object via call to objc_loadWeakRetained(), followng it by objc_release
at appropriate place, thereby removing the hidden autorelease. // rdar://10849570
llvm-svn: 168740
|
| |
|
|
|
|
| |
Also fixes a bit/byte mismatch when checking if a target supports atomic ops of a certain size.
llvm-svn: 168260
|
| |
|
|
|
|
|
|
| |
bits in memory).
PR11777.
llvm-svn: 167802
|
| |
|
|
|
|
|
| |
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
llvm-svn: 167413
|
| |
|
|
| |
llvm-svn: 167261
|
| |
|
|
|
|
| |
separate functions, since they share essentially no code.
llvm-svn: 167259
|
| |
|
|
|
|
|
|
| |
We want the diagnostic, and if the load is optimized away, we still want to
trap it. Stop checking non-default address spaces; that doesn't work in
general.
llvm-svn: 167219
|
| |
|
|
| |
llvm-svn: 166992
|
| |
|
|
| |
llvm-svn: 166853
|
| |
|
|
| |
llvm-svn: 166849
|