We need to abort the formation of counter-register-based loops where there are
128-bit integer operations that might become function calls.

llvm-svn: 202192

llvm-svn: 202191

Now that DataLayout is not a pass, store one in Module.

Since the C API expects to be able to get a char* to the datalayout description,
we have to keep a std::string somewhere. This patch keeps it in Module and also
uses it to represent modules without a DataLayout.

Once DataLayout is mandatory, we should probably move the string to DataLayout
itself since it won't be necessary anymore to represent the special case of a
module without a DataLayout.

llvm-svn: 202190

Also fix the bug where lldb prints: "Got a connection and launched debugserver" rather
than the name of the process it actually launched.

llvm-svn: 202189

Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.

Paired commit with CFE r202185.

rdar://problem/13690847

This re-applies r202184 + a bugfix in DwarfDebug's argument handling.

llvm-svn: 202188

This reverts commit r202184 because of buildbot breakage.

llvm-svn: 202187

llvm-svn: 202186

Paired commit with LLVM.

rdar://problem/13690847

llvm-svn: 202185

Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.

Paired commit with CFE.

rdar://problem/13690847

llvm-svn: 202184

llvm-svn: 202183

llvm-svn: 202182

llvm-svn: 202181

<rdar://problem/16115219>

llvm-svn: 202180

llvm-svn: 202179

Generating RTTI in the MS ABI is currently not supported, and the failures
are confusing to users, so let's disable it by default for now.

llvm-svn: 202178

-march which doesnt exist on sparc gcc to -mcpu. While here adjust a
few tests to not write an unused temporary file.

llvm-svn: 202177

Reads the description of a virtual filesystem from a file and overlays
it over the real file system.

llvm-svn: 202176

This was changed to use manual desugaring and multiplication in r201832
and fixed for multi-dimensional arrays in r201917.  However, it breaks
down in the presence of typedefs.  Rather than attempting to handle all
the desugaring, just go back to calling the generic type info code.

This was discovered while compiling SIInstrWaits.cpp in the R600
backend.

llvm-svn: 202175

There were many additional tests that had the bad behavior baked in.

llvm-svn: 202174

This reverts commit r202167.

It broke Analysis/auto-obj-dtors-cfg-output.cpp

llvm-svn: 202173

llvm-svn: 202172

llvm-svn: 202171

llvm-svn: 202170

Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM
don't don't handle passes to also use DataLayout.

llvm-svn: 202168

- Don't emit anything when we encounter a call to a conversion operator.
    "bar(a & b)" instead of "bar(a & b.operator int())"
  This preserves the semantics and is still idempotent if we print the AST multiple times.

- Properly print declarations of conversion operators.
    "explicit operator bool();" instead of "bool operator _Bool();"

PR18776.

llvm-svn: 202167

llvm-svn: 202166

The function with uwtable attribute might be visited by the
stack unwinder, thus the link register should be considered
as clobbered after the execution of the branch and link
instruction (i.e. the definition of the machine instruction
can't be ignored) even when the callee function are marked
with noreturn.

llvm-svn: 202165

Summary:
Contains a short user's manual and some instructions on writing
clang-tidy checks.

Reviewers: klimek, djasper

Reviewed By: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2880

llvm-svn: 202164

The behaviour of the XCore's instruction buffer means that the performance
of the same code sequence can differ depending on whether it starts at a 4
byte aligned address or not. Since we don't model the instruction buffer
in the backend we have no way of knowing for sure if it is beneficial to
word align a specific function. However, in the absence of precise
modelling, it is better on balance to word align functions because:

* It makes a fetch-nop while executing the prologue slightly less likely.
* If we don't word align functions then a small perturbation in one
  function can have a dramatic knock on effect. If the size of the function
  changes it might change the alignment and therefore the performance of
  all the functions that happen to follow it in the binary. This butterfly
  effect makes it harder to reason about and measure the performance of
  code.

llvm-svn: 202163

llvm-svn: 202162

Mark LWG Issues 2278 and 2313 as complete. No code changes needed; libc++ already implemented both of these.

llvm-svn: 202161

llvm-svn: 202158

llvm-svn: 202157

llvm-svn: 202156

llvm-svn: 202155

  Don't actually Halt in the Interrupt handler for the Process, just
  send an AsyncInterrupt.  That's actually not async-signal-clean, but
  it is a lot safer than Halt...

The underlying problem is actually a nested pthread_cond_wait from the
signal handler.  Note frames 4, 13, 18 in the backtrace of the aborting
path below.

    frame #1: 0x000000080715fff9 libc.so.7`abort + 73 at abort.c:65
    frame #2: 0x0000000805d20fda libthr.so.3`_thread_exit(fname=<unavailable>, lineno=<unavailable>, msg=<unavailable>) + 58 at thr_exit.c:182
    frame #3: 0x0000000805d1fdc8 libthr.so.3`cond_wait_common [inlined] cond_wait_user(mp=<unavailable>, abstime=<unavailable>, cancel=<unavailable>) + 936 at thr_cond.c:223
    frame #4: 0x0000000805d1fd5b libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=<unavailable>, cancel=<unavailable>) + 827 at thr_cond.c:311
    frame #5: 0x00000008013450b5 liblldb.so.3.5`lldb_private::Condition::Wait(lldb_private::Mutex&, lldb_private::TimeValue const*, bool*) + 117
    frame #6: 0x00000008013411e8 liblldb.so.3.5`lldb_private::Predicate<bool>::WaitForValueEqualTo(bool, lldb_private::TimeValue const*, bool*) + 200
    frame #7: 0x00000008013eb34c liblldb.so.3.5`lldb_private::Listener::WaitForEventsInternal(lldb_private::TimeValue const*, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int, std::__1::shared_ptr<lldb_private::Event>&) + 876
    frame #8: 0x00000008013eb751 liblldb.so.3.5`lldb_private::Listener::WaitForEvent(lldb_private::TimeValue const*, std::__1::shared_ptr<lldb_private::Event>&) + 81
    frame #9: 0x00000008017c5bcf liblldb.so.3.5`lldb_private::Process::Halt(bool) + 783
    frame #10: 0x00000008017def3a liblldb.so.3.5`IOHandlerProcessSTDIO::Interrupt() + 74
    frame #11: 0x00000008013823d3 liblldb.so.3.5`lldb_private::Debugger::DispatchInputInterrupt() + 115
    frame #12: 0x00000008011d69c5 liblldb.so.3.5`lldb::SBDebugger::DispatchInputInterrupt() + 69
    frame #13: 0x000000000040b254 lldb`sigint_handler(int) + 68
    frame #14: 0x0000000805d1b3da libthr.so.3`handle_signal(actp=<unavailable>, sig=<unavailable>, info=<unavailable>, ucp=<unavailable>) + 234 at thr_sig.c:240
    frame #15: 0x0000000805d1afc2 libthr.so.3`thr_sighandler(sig=<unavailable>, info=<unavailable>, _ucp=<unavailable>) + 306 at thr_sig.c:183
    frame #16: 0x00007ffffffff003
    frame #17: 0x0000000805d1fc7e libthr.so.3`cond_wait_common [inlined] cond_wait_user(mp=<unavailable>, abstime=<unavailable>, cancel=1) + 239 at thr_cond.c:255
    frame #18: 0x0000000805d1fb8f libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=0x0000000000000000, cancel=1) + 367 at thr_cond.c:311
    frame #19: 0x00000008013450d2 liblldb.so.3.5`lldb_private::Condition::Wait(lldb_private::Mutex&, lldb_private::TimeValue const*, bool*) + 146

llvm-svn: 202154

llvm-svn: 202153

The 'f' modifier is designed for integer type arguments really (according to
its documentation). It's better to use the "half width, same number" modifier.

Should be no user-visible change.

llvm-svn: 202152

llvm-svn: 202151

Partially based on http://llvm-reviews.chandlerc.com/D2644 by Viktor Kutuzov.

llvm-svn: 202150