- 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

[ASan] Allow ASan default runtime options be overriden at compile time by providing ASAN_DEFAULT_OPTIONS macro

llvm-svn: 175512

llvm-svn: 175511

llvm-svn: 175510

Fix initialization-order bug in llvm::Support::TimeValue. TimeValue::now() 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

Fix a bug in mutex_try_to_lock.  This was previously trying to unlock a 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

[Sanitizer] If -fsanitize-blacklist= option is not explicitly specified, 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

llvm-svn: 175487

BtnezT8SltiX16, BtnezT8SltiuX16 .

llvm-svn: 175486

llvm-svn: 175485

llvm-svn: 175484

Fixing a typo where FixIts was accidentally self-assigning instead of assigning in the parameter Fixits. This fixes several failed assertions with MSVC debug builds.

llvm-svn: 175483