llvm-svn: 181019

llvm-svn: 181018

Before: for (; a&& b;) {}
After:  for (; a && b;) {}
llvm-svn: 181017

The soon-to-be-committed SystemZ port uses 128-bit IEEE floats.
MIPS64 GNU/Linux does too (albeit with unusual NaNs).

llvm-svn: 181016

Another step towards reinstating the SystemZ backend.  I'll commit
the configure changes separately (TARGET_HAS_JIT etc.), then commit
a patch to enable the MCJIT tests on SystemZ.

llvm-svn: 181015

Patch by Ismail Pazarbasi.

llvm-svn: 181011

[SystemZ] Support System Z as host architecture

The llvm::sys::AddSignalHandler function (as well as related routines) in
lib/Support/Unix/Signals.inc currently registers a signal handler routine
via "sigaction".  When this handler is called due to a SIGSEGV, SIGILL or
similar signal, it will show a stack backtrace, deactivate the handler,
and then simply return to the operating system.  The intent is that the
OS will now retry execution at the same location as before, which ought
to again trigger the same error condition and cause the same signal to be
delivered again.  Since the hander is now deactivated, the OS will take
its default action (usually, terminate the program and possibly create
a core dump).

However, this method doesn't work reliably on System Z:  With certain
signals (namely SIGILL, SIGFPE, and SIGTRAP), the program counter stored
by the kernel on the signal stack frame (which is the location where
execution will resume) is not the instruction that triggered the fault,
but then instruction *after it*.  When the LLVM signal handler simply
returns to the kernel, execution will then resume at *that* address,
which will not trigger the problem again, but simply go on and execute
potentially unrelated code leading to random errors afterwards.

To fix this, the patch simply goes and re-raises the signal in question
directly from the handler instead of returning from it.  This is done
only on System Z and only for those signals that have this particular
problem.

llvm-svn: 181010

Build attribute sections can now be read if they exist via ELFObjectFile, and
the llvm-readobj tool has been extended with an option to dump this information
if requested. Regression tests are also included which exercise these features.

Also update the docs with a fixed ARM ABI link and a new link to the Addenda
which provides the build attributes specification.

llvm-svn: 181009

Another step towards reinstating the SystemZ backend.  Tests will be
included in the main backend patch.

llvm-svn: 181008

First step towards reinstating the SystemZ backend.  Tests will be
included in the main backend patch.

llvm-svn: 181007

llvm-svn: 181006

llvm-svn: 181005

MSVC provides __wchar_t, either as an alias for the built-in wchar_t
type, or as a separate type depending on language (C vs C++) and flags
(-fno-wchar).

In -fms-extensions, Clang will simply accept __wchar_t as an alias for
whatever type is used for wide character literals. In -fms-compatibility, we
try to mimic MSVC's behavior by always making __wchar_t a builtin type.

This fixes PR15815.

llvm-svn: 181004

llvm-svn: 181001

a lambda.

Bug #1 is that CGF's CurFuncDecl was "stuck" at lambda invocation
functions.  Fix that by generally improving getNonClosureContext
to look through lambdas and captured statements but only report
code contexts, which is generally what's wanted.  Audit uses of
CurFuncDecl and getNonClosureAncestor for correctness.

Bug #2 is that lambdas weren't specially mapping 'self' when inside
an ObjC method.  Fix that by removing the requirement for that
and using the normal EmitDeclRefLValue path in LoadObjCSelf.

rdar://13800041

llvm-svn: 181000

FindLastStoreBRVisitor is responsible for finding where a particular region
gets its value; if the region is a VarRegion, it's possible that value was
assigned at initialization, i.e. at its DeclStmt. However, if a function is
called recursively, the same DeclStmt may be evaluated multiple times in
multiple stack frames. FindLastStoreBRVisitor was not taking this into
account and just picking the first one it saw.

<rdar://problem/13787723>

llvm-svn: 180997

There were actually two bugs here:
- if we decided to look for an interesting lvalue or call expression, we
  wouldn't go find its node if we also knew we were at a (different) call.
- if we looked through one message send with a  nil receiver, we thought we
  were still looking at an argument to the original call.

Put together, this kept us from being able to track the right values, which
means sub-par diagnostics and worse false-positive suppression.

Noticed by inspection.

llvm-svn: 180996

thread before UnwindLLDB::AddOneMoreFrame calls it quits.  We have
a couple of reports of unending backtraces in the field and we
haven't been able to collect any information about what kind of
backtrace is causing this.  We've found on Mac OS X that it's tricky
to get more than around 200k stack frames before a process exceeds
its stack space so we're starting with a hard limit of 300,000 frames.
<rdar://problem/13383069> 

llvm-svn: 180995

llvm-svn: 180994

llvm-svn: 180993

llvm-svn: 180992

llvm-svn: 180991

This reverts commit 180982.

llvm-svn: 180990

match when looking at kext on the local filesystem.
<rdar://problem/13785112> 

llvm-svn: 180989

llvm-svn: 180988

SWIG is smart enough to recognize that C++ operators == and != mean __eq__ and __ne__ in Python and do the appropriate translation
But it is not smart enough to recognize that mySBObject == None should return False instead of erroring out
The %pythoncode blocks are meant to provide those extra smarts (and they play some SWIG&Python magic to find the right function to call behind the scenes with no risk of typos :-)
Lastly, SBBreakpoint provides an == but never provided a != operator - common courtesy is to provide both

llvm-svn: 180987

llvm-svn: 180986

Without any conversion, this is pretty straightforward.  Most of the
fields can be zeros.  The order is:

- field offset or pointer
- nonvirtual adjustment (for MI functions)
- vbptr offset (for unspecified)
- virtual adjustment offset (for virtual inheritance)

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

llvm-svn: 180985

Make sure to handle all thumb variants correctly.

llvm-svn: 180984

llvm-svn: 180983

- Use the debug location of the return expression for the cleanup code
  if the return expression is trivially evaluatable, regardless of the
  number of stop points in the function.
- Ensure that any EH code in the cleanup still gets the line number of
  the closing } of the lexical scope.
- Added a testcase with EH in the cleanup.

rdar://problem/13442648

llvm-svn: 180982

of a weird merge error with git.

llvm-svn: 180981

Use unbuffered I/O. This reduces the runtime by about half. Our implementation is now only about 5 times slower than gcc's.

llvm-svn: 180980

This reverts commit 180974. It broke the build.

llvm-svn: 180979

the "identifier" parsed by the frontend callback by skipping forward
until we've consumed a token that ends at the point dictated by the
callback.

In addition, inform the callback when it's parsing an unevaluated
operand (e.g. mov eax, LENGTH A::x) as opposed to an evaluated one
(e.g. mov eax, [A::x]).

This commit depends on a clang commit.

llvm-svn: 180978

llvm-svn: 180977

the actual parser and support arbitrary id-expressions.

We're actually basically set up to do arbitrary expressions here
if we wanted to.

Assembly operands permit things like A::x to be written regardless
of language mode, which forces us to embellish the evaluation
context logic somewhat.  The logic here under template instantiation
is incorrect;  we need to preserve the fact that an expression was
unevaluated.  Of course, template instantiation in general is fishy
here because we have no way of delaying semantic analysis in the
MC parser.  It's all just fishy.

I've also fixed the serialization of MS asm statements.

This commit depends on an LLVM commit.

llvm-svn: 180976

Allow command script import to load packages.

e.g.:
egranata$ ./lldb
(lldb) command script import lldb.macosx.crashlog
"crashlog" and "save_crashlog" command installed, use the "--help" option for detailed help
"malloc_info", "ptr_refs", "cstr_refs", and "objc_refs" commands have been installed, use the "--help" options on these commands for detailed help.
The "unwind-diagnose" command has been installed, type "help unwind-diagnose" for detailed help.
(lldb) 

./lldb
(lldb) command script import theFoo
I am happy
(lldb) fbc
àèìòù
(lldb)

egranata$ ls theFoo/
__init__.py theBar.py

egranata$ cat theFoo/__init__.py 
import lldb
import theBar

def __lldb_init_module(debugger, internal_dict):
	print "I am happy"
	debugger.HandleCommand("command script add -f theFoo.theBar.theCommand fbc")
	return None

egranata$ cat theFoo/theBar.py 
#encoding=utf-8

def theCommand(debugger, command, result, internal_dict):
	result.PutCString(u"àèìòù")
	return None

llvm-svn: 180975

BugReporter is used to process ALL bug reports.  By using a shared map,
we are having mappings from different PathDiagnosticPieces to LocationContexts
well beyond the point where we are processing a given report.  This
state is inherently error prone, and is analogous to using a global
variable.  Instead, just create a temporary map, one per report,
and when we are done with it we throw it away.  No extra state.

llvm-svn: 180974

This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":

 template<unsigned Size, unsigned Align>
 class my_aligned_storage
 {
   __attribute__((align((Align)))) char storage[Size];
 };

while this would parse as a "parameter name" 'Align':

 template<unsigned Size, unsigned Align>
 class my_aligned_storage
 {
   __attribute__((align(Align))) char storage[Size];
 };

The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to

 template<unsigned Size, unsigned Align>
 class my_aligned_storage
 {
   __attribute__((align)) char storage[Size];
 };

i.e., use the maximal alignment rather than the specified alignment.

Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.

Fixes <rdar://problem/13700933>.

llvm-svn: 180973