| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 175539
|
|
|
|
|
|
| |
unit test.
llvm-svn: 175538
|
|
|
|
|
|
| |
HexagonInstrFormats.td.
llvm-svn: 175537
|
|
|
|
|
|
| |
No intended functionality change.
llvm-svn: 175536
|
|
|
|
|
|
|
|
|
|
|
| |
I don't want to rule out the possibility of linking to e.g. interesting
blog posts about uses of Clang, so avoid restricting the content to
"projects".
This breaks URL compatibility, but this document was committed less than
an hour ago so hopefully nobody has linked to it yet.
llvm-svn: 175535
|
|
|
|
| |
llvm-svn: 175534
|
|
|
|
|
|
|
|
|
| |
We can now format:
#define A template <typename T>
Before this created a segfault :-/.
llvm-svn: 175533
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using a new metafunction for detecting the presence of the member
'getDecl' in a type T, added support to hasDeclaration for any such type
T. This allows hasDecl() to be replaced and enables several other
subclasses of clang::Type to use hasDeclaration.
Updated unittests and LibASTMatchersReference.html.
Reviewers: klimek
llvm-svn: 175532
|
|
|
|
|
|
| |
PPCJITInfo.cpp in r175394.
llvm-svn: 175531
|
|
|
|
| |
llvm-svn: 175530
|
|
|
|
|
|
|
|
|
| |
A couple concrete examples are sure to be a win. If you know of any
other external projects using Clang, please let me know!
Patch by Laszlo Nagy! (with a title tweak by me)
llvm-svn: 175529
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the execution order of doFinalization functions, the GC information were
deleted before AsmPrinter::doFinalization was executed. Thus, the
GCMetadataPrinter::finishAssembly was never called.
The patch fixes that by moving the code of the GCInfoDeleter::doFinalization to
Printer::doFinalization.
llvm-svn: 175528
|
|
|
|
| |
llvm-svn: 175527
|
|
|
|
| |
llvm-svn: 175525
|
|
|
|
|
|
|
|
| |
- rework the way SBDebugger.SetAsync() is used to avoid side effects (reset original value at TearDownHook)
- refactor expectedFailureClang (and add expectedFailureGcc decorator)
- mark TestChangeValueAPI.py as expectedFailureGcc due to PR-15039
llvm-svn: 175523
|
|
|
|
|
|
| |
- do not pass (incompatible option) -stdlib=libstdc++ option if using GCC as test compiler
llvm-svn: 175522
|
|
|
|
|
|
| |
- Should allow tests to run without 'clang' installed
llvm-svn: 175521
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A vectorized sitfp on doubles will get scalarized to a sequence of an
extract_element of <2 x i32>, a bitcast to f32 and a sitofp.
Due to the the extract_element, and the bitcast we will uneccessarily generate
moves between scalar and vector registers.
The patch fixes this by using a COPY_TO_REGCLASS and a EXTRACT_SUBREG to extract
the element from the vector instead.
radar://13191881
llvm-svn: 175520
|
|
|
|
|
| |
NOTE: This is a candidate for the Mesa stable branch.
llvm-svn: 175519
|
|
|
|
|
|
|
|
| |
This stops the Machine Verifier from complaining about uses of undefined
physical registers.
NOTE: This is a candidate for the Mesa stable branch.
llvm-svn: 175518
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kernel function arguments are lowered to loads from the PARAM_I address
space. When creating these load instructions, we were initializing
their MachinePointerInfo with an Arguement object that was not attached
to any function. This was causing the MachineScheduler to crash when
it tried to access the parent of the Arguement.
This has been fixed by initializing the MachinePointerInfo with a
UndefValue instead.
NOTE: This is a candidate for the Mesa stable branch.
llvm-svn: 175517
|
|
|
|
|
|
|
|
|
| |
In some cases, we were losing track of live implicit registers which
was creating dead defs and causing the scheduler to produce invalid
code.
NOTE: This is a candidate for the Mesa stable branch.
llvm-svn: 175516
|
|
|
|
| |
llvm-svn: 175515
|
|
|
|
| |
llvm-svn: 175514
|
|
|
|
|
|
| |
This way it fits on a random 1G device.
llvm-svn: 175513
|
|
|
|
|
|
| |
providing ASAN_DEFAULT_OPTIONS macro
llvm-svn: 175512
|
|
|
|
| |
llvm-svn: 175511
|
|
|
|
| |
llvm-svn: 175510
|
|
|
|
|
|
| |
is explicitly called during module initialization of lib/Support/Process.cpp. It reads the field of global object PosixZeroTime, which is not guaranteed to be initialized at this point. Found by AddressSanitizer with -fsanitize=init-order option.
llvm-svn: 175509
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes asan instrument memory accesses with unusual sizes (e.g. 5 bytes or 10 bytes), e.g. long double or
packed structures.
Instrumentation is done with two 1-byte checks
(first and last bytes) and if the error is found
__asan_report_load_n(addr, real_size) or
__asan_report_store_n(addr, real_size)
is called.
asan-rt part
Also fix lint.
llvm-svn: 175508
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes asan instrument memory accesses with unusual sizes (e.g. 5 bytes or 10 bytes), e.g. long double or
packed structures.
Instrumentation is done with two 1-byte checks
(first and last bytes) and if the error is found
__asan_report_load_n(addr, real_size) or
__asan_report_store_n(addr, real_size)
is called.
Also, call these two new functions in memset/memcpy
instrumentation.
asan-rt part will follow.
llvm-svn: 175507
|
|
|
|
|
|
|
|
|
|
| |
mutex that it didn't own, causing an assertion failure in mutex.cpp. The issue was that the unique_lock went out of scope, releasing the lock on m, then m.unlock() was called on an already-unlocked mutex.
This change removes the spurious m.unlock() call.
If this test was previously passing for anyone with assertions enabled, then they should investigate bugs in their pthread implementation, as pthread_unlock() should not return 0 if the mutex is currently unlocked.
llvm-svn: 175506
|
|
|
|
|
|
| |
make Clang look for the default sanitizer-specific blacklist in the resource directory.
llvm-svn: 175505
|
|
|
|
|
|
|
| |
execle(argv[0], ...) is wrong, because argv[0] may contain a PATH-resolvable
program name. Execute /proc/self/exe instead.
llvm-svn: 175504
|
|
|
|
| |
llvm-svn: 175503
|
|
|
|
| |
llvm-svn: 175502
|
|
|
|
| |
llvm-svn: 175501
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The key bug was
if (Other.StartOfLineLevel < StartOfLineLevel) ..
instead of
if (Other.StartOfLineLevel != StartOfLineLevel) ..
Also cleaned up the function to be more consistent in the comparisons.
llvm-svn: 175500
|
|
|
|
| |
llvm-svn: 175499
|
|
|
|
| |
llvm-svn: 175498
|
|
|
|
| |
llvm-svn: 175497
|
|
|
|
|
|
| |
twice.
llvm-svn: 175496
|
|
|
|
|
|
|
|
|
|
|
| |
to search for kexts on the local system -- the ModuleList FindModule()
method is the best first attempt, only call
Symbols::DownloadObjectAndSymbolFile() if that has failed and this
is the kernel binary which really needs to have its symbols located.
<rdar://problem/13241893>
llvm-svn: 175495
|
|
|
|
|
|
|
|
|
|
|
| |
find a binary on the debugger-host during a kernel debug session
for a kernel extension (kext). This may prove to be too verbose
in typical usage, particularly if there are many third-party kexts.
We'll try this and see how it works.
<rdar://problem/13080833>
llvm-svn: 175494
|
|
|
|
| |
llvm-svn: 175493
|
|
|
|
| |
llvm-svn: 175492
|
|
|
|
|
|
|
|
|
|
|
| |
a kernel binary - even if we can't find the symbol-rich binary or
dSYM on the debugger-system. Print a warning if the symbol-rich binary
cannot be located. This more closely emulates the gdb behavior when
a kernel debug session failed to locate a kernel binary.
<rdar://problem/13016095>
llvm-svn: 175491
|
|
|
|
| |
llvm-svn: 175490
|
|
|
|
|
|
|
|
|
|
|
|
| |
of kernel extensions (kexts) that have been loaded into the kernel.
Now when we hit the "kexts have changed" breakpoint we can avoid
adding kexts multiple times, and can properly detect kext unloads
and remove them from the Target's list of modules.
<rdar://problem/13107639>
<rdar://problem/13191016>
llvm-svn: 175489
|
|
|
|
| |
llvm-svn: 175488
|