| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
configuration that would take advantage of this. But it has popped up in the wild and does no harm to support it.
llvm-svn: 164575
|
| |
|
|
|
|
| |
crash
llvm-svn: 164574
|
| |
|
|
|
|
|
|
|
|
| |
which builds a Debug+Asserts build of Clang and
links LLDB against it. The Debug configuration
builds Clang with Release+Asserts, for faster
linking and smaller memory footprint when debugging
the build LLDB.
llvm-svn: 164573
|
| |
|
|
| |
llvm-svn: 164572
|
| |
|
|
|
|
|
|
|
| |
Even out-of-line jump tables can be in the code section, so mark them
as data-regions for those targets which support the directives.
rdar://12362871&12362974
llvm-svn: 164571
|
| |
|
|
| |
llvm-svn: 164570
|
| |
|
|
|
|
| |
unused expression warnings. <rdar://problem/12359208>.
llvm-svn: 164569
|
| |
|
|
| |
llvm-svn: 164568
|
| |
|
|
|
|
| |
Also remove an unused argument.
llvm-svn: 164567
|
| |
|
|
|
|
| |
to the feature.
llvm-svn: 164566
|
| |
|
|
|
|
|
|
|
| |
I also moved the SDKROOT setting into the make flags, since clearing it from
the environment isn't good enough to override a setting on the make command
line. That hasn't been a problem but it could be, and it's good to be
consistent with the way UNIVERSAL_SDK_PATH is handled.
llvm-svn: 164565
|
| |
|
|
|
|
|
|
| |
that volatile registers are correctly reported for this ABI.
We were incorrectly passing up volatile registers from callee
frames.
llvm-svn: 164564
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
top-of-tree. Removed all local patches and llvm.zip.
The intent is that fron now on top-of-tree will
always build against LLVM/Clang top-of-tree, and
that problems building will be resolved as they
occur. Stable release branches of LLDB can be
constructed as needed and linked to specific release
branches of LLVM/Clang.
llvm-svn: 164563
|
| |
|
|
|
|
| |
dead.
llvm-svn: 164561
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 164560
|
| |
|
|
|
|
|
| |
'instance variable' in text of all diagnostics
for objective-C: // rdar://12352442
llvm-svn: 164559
|
| |
|
|
|
|
|
| |
"frame variable". "expr" finds hidden ivars
correctly.
llvm-svn: 164558
|
| |
|
|
| |
llvm-svn: 164557
|
| |
|
|
| |
llvm-svn: 164556
|
| |
|
|
| |
llvm-svn: 164555
|
| |
|
|
| |
llvm-svn: 164554
|
| |
|
|
|
|
|
| |
store when handling byval arguments. Thus preventing reordering of the store
with load with post-RA scheduler.
llvm-svn: 164553
|
| |
|
|
| |
llvm-svn: 164551
|
| |
|
|
| |
llvm-svn: 164550
|
| |
|
|
|
|
|
| |
the fact. Test cases will come when we're actually (de-)serializing
macro history.
llvm-svn: 164549
|
| |
|
|
| |
llvm-svn: 164548
|
| |
|
|
|
|
|
| |
This was renamed in r162632 which was badness because the C API needs to be stable.
rdar://12360096
llvm-svn: 164547
|
| |
|
|
|
|
| |
silenced by -Wno-long-long. Thanks Richard Smith for the fix idea!
llvm-svn: 164546
|
| |
|
|
|
|
|
|
|
| |
> 'long long' is an extension when C99 mode is not enabled
to
> 'long long' is a C++11 extension
while compiling in C++98 mode.
llvm-svn: 164545
|
| |
|
|
| |
llvm-svn: 164544
|
| |
|
|
|
|
|
| |
Thanks to Byoungyoung for realizing taht we are not passing the default
option correctly.
llvm-svn: 164543
|
| |
|
|
| |
llvm-svn: 164542
|
| |
|
|
|
|
| |
(Unfortunately, I do not have a good reduced test case for this.)
llvm-svn: 164541
|
| |
|
|
| |
llvm-svn: 164540
|
| |
|
|
|
|
| |
This avoids a crash in visitAllocaInst when target data isn't available.
llvm-svn: 164539
|
| |
|
|
| |
llvm-svn: 164490
|
| |
|
|
| |
llvm-svn: 164489
|
| |
|
|
|
|
| |
thread so that sleep-synchronization will be detected even if child thread is started late.
llvm-svn: 164488
|
| |
|
|
|
|
| |
extern C functions with weirdly mangled names (same strategy is used in ASan).
llvm-svn: 164487
|
| |
|
|
|
|
| |
same time, remove ASan from CMake build on Windows after conversation with Timur. We don't want to support building ASan on Windows until it is in a working state.
llvm-svn: 164486
|
| |
|
|
|
|
| |
building for Darwin with -faddress-sanitizer.
llvm-svn: 164485
|
| |
|
|
|
|
|
| |
StringRef makes code cleaner. Also, make the temporary buffer smaller:
512 characters is unreasonably large for integer literals.
llvm-svn: 164484
|
| |
|
|
| |
llvm-svn: 164483
|
| |
|
|
|
|
|
| |
the new SROA pass. This is a benign change: the order of PHI nodes
changed.
llvm-svn: 164481
|
| |
|
|
|
|
| |
Queue the fallout. ;]
llvm-svn: 164480
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer promotion analogous to vector promotion. When there is an
integer alloca being accessed both as its integer type and as a narrower
integer type, promote the narrower access to "insert" and "extract" the
smaller integer from the larger one, and make the integer alloca
a candidate for promotion.
In the new formulation, we don't care about target legal integer or use
thresholds to control things. Instead, we only perform this promotion to
an integer type which the frontend has already emitted a load or store
for. This bounds the scope and prevents optimization passes from
coalescing larger and larger entities into a single integer.
llvm-svn: 164479
|
| |
|
|
|
|
|
|
| |
"0x100000000i128 => 4294967296L", for now.
LONG_MAX is 2147483647L on common 32 bit and LLP64 (Windows x64).
llvm-svn: 164478
|
| |
|
|
|
|
| |
printing directly rather than through a complicated machinery of ObjC rewriter.
llvm-svn: 164477
|
| |
|
|
|
|
| |
Patch by Kai!
llvm-svn: 164476
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
across the uses of the alloca. It's entirely possible for negative
numbers to come up here, and in some rare cases simply doing the 2's
complement arithmetic isn't the correct decision. Notably, we can't zext
the index of the GEP. The definition of GEP is that these offsets are
sign extended or truncated to the size of the pointer, and then wrapping
2's complement arithmetic used.
This patch fixes an issue that comes up with *no* input from the
buildbots or bootstrap afaict. The only place where it manifested,
disturbingly, is Clang's own regression test suite. A reduced and
targeted collection of tests are added to cope with this. Note that I've
tried to pin down the potential cases of overflow, but may have missed
some cases. I've tried to add a few cases to test this, but its hard
because LLVM has quite limited support for >64bit constructs.
llvm-svn: 164475
|