Before:
  x[(uint8) y];
  x = (uint8) y;
  void f() { x = (uint8) y; }
  #define AA(X) sizeof(((X *) NULL)->a)

After:
  x[(uint8)y];
  x = (uint8)y;
  void f() { x = (uint8)y; }
  #define AA(X) sizeof(((X *)NULL)->a)

llvm-svn: 183014

Patch by Amaury de la Vieuville.

llvm-svn: 183012

These instructions are deprecated oddities, but we still need to be able to
disassemble (and reassemble) them if and when they're encountered.

Patch by Amaury de la Vieuville.

llvm-svn: 183011

llvm-svn: 183010

If a "}" is found inside parenthesis, this is probably a case of
missing parenthesis. This enables continuing to format after stuff code
like:

class A {
  void f(
};
..

llvm-svn: 183009

With this patch, the simplified rule is:
If the block is part of a declaration (class, namespace, function,
enum, ..), merge an empty block onto a single line. Otherwise
(specifically for the compound statements of if, for, while, ...),
keep the braces on two separate lines.

The reasons are:
- Mostly the formatting of empty blocks does not matter much.
- Empty compound statements are really rare and are usually just
  inserted while still working on the code. If they are on two lines,
  inserting code is easier. Also, overlooking the "{}" of an
  "if (...) {}" can be really bad.
- Empty declarations are not uncommon, e.g. empty constructors. Putting
  them on one line saves vertical space at no loss of readability.

llvm-svn: 183008

Before:
bool aaaaaa = aaaaaaaaaaaaa //
                  ? aaaaaaaaaaaaaaa
                  : bbbbbbbbbbbbbbb //
                  ? ccccccccccccccc
                  : ddddddddddddddd;

After:
bool aaaaaa = aaaaaaaaaaaaa //
                  ? aaaaaaaaaaaaaaa
                  : bbbbbbbbbbbbbbb //
                        ? ccccccccccccccc
                        : ddddddddddddddd;

llvm-svn: 183007

llvm-svn: 183006

Patch by Andrea Di Biagio.

llvm-svn: 183005

llvm-svn: 183004

The disassembly of VEXT instructions was too lax in the bits checked. This
fixes the case where the instruction affects Q-registers but a misaligned lane
was specified (should be UNDEFINED).

Patch by Amaury de la Vieuville

llvm-svn: 183003

Unlike most -- hopefully "all other", but I'm still checking -- memory
instructions we support, LOAD REVERSED and STORE REVERSED may access
the memory location several times.  This means that they are not suitable
for volatile loads and stores.

This patch is a prerequisite for better atomic load and store support.
The same principle applies there: almost all memory instructions we
support are inherently atomic ("block concurrent"), but LOAD REVERSED
and STORE REVERSED are exceptions.

Other instructions continue to allow volatile operands.  I will add
positive "allows volatile" tests at the same time as the "allows atomic
load or store" tests.

llvm-svn: 183002

Added a new option -override-macros which causes the, the add-override
transform to detect macros that expand to 'override' (like LLVM_OVERRIDE) and
use these macros instead of the override keyword directly.

llvm-svn: 183001

Change the LSan lit test logic. Now "check-lsan" tests the leak
checking functionality in both standalone LSan and ASan.

llvm-svn: 183000

llvm-svn: 182999

Now that 3.3 is branched, we are re-enabling virtual registers to help
iron out bugs before the next release. Some of the post-RA passes do
not play well with virtual registers, so we disable them for now. The
needed functionality of the PrologEpilogInserter pass is copied to a
new backend-specific NVPTXPrologEpilog pass.

The test for this commit is not breaking the existing tests.

llvm-svn: 182998

Before this change, each module defined a weak_odr global __msan_track_origins 
with a value of 1 if origin tracking is enabled, 0 if disabled. If there are 
modules with different values, any of them may win. If 0 wins, and there is at 
least one module with 1, the program will most likely crash.

With this change, __msan_track_origins is only emitted if origin tracking is 
on. Then runtime library detects if there is at least one module with origin 
tracking, and enables runtime support for it.

llvm-svn: 182997

Before this change, each module defined a weak_odr global __msan_track_origins
with a value of 1 if origin tracking is enabled, 0 if disabled. If there are
modules with different values, any of them may win. If 0 wins, and there is at
least one module with 1, the program will most likely crash.

With this change, __msan_track_origins is only emitted if origin tracking is
on. Then runtime library detects if there is at least one module with origin
tracking, and enables runtime support for it.

llvm-svn: 182996

llvm-svn: 182995

llvm-svn: 182994

Add compile time tests for sizes and offsets of all sanitizer-posix types.

llvm-svn: 182993

Before:
foo = aaaaaaaaaaa ? vector<int> {
  aaaaaaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa, aaaaa
}
: vector<int>{ bbbbbbbbbbbbbbbbbbbbbbbbbbb, bbbbbbbbbbbbbbbbbbbb, bbbbb };

After:
foo = aaaaaaaaaaa ? vector<int>{ aaaaaaaaaaaaaaaaaaaaaaaaaaa,
                                 aaaaaaaaaaaaaaaaaaaa, aaaaa }
                  : vector<int>{ bbbbbbbbbbbbbbbbbbbbbbbbbbb,
                                 bbbbbbbbbbbbbbbbbbbb, bbbbb };

llvm-svn: 182992

The MOV64ri64i32 instruction required hacky MCInst lowering because it was
allocated as setting a GR64, but the eventual instruction ("movl") only set a
GR32. This converts it into a so-called "MOV32ri64" which still accepts a
(appropriate) 64-bit immediate but defines a GR32. This is then converted to
the full GR64 by a SUBREG_TO_REG operation, thus keeping everyone happy.

llvm-svn: 182991

llvm-svn: 182990

Fixes PR16130 - clang produces incorrect code with loop/expression at -O2.

This is a 2+ year old bug that's now holding up the release. It's a
case where we knowingly made aggressive assumptions about undefined
behavior. These assumptions are wrong when SCEV is computing a
subexpression that does not directly control the branch. With this
fix, we avoid making assumptions in those cases but still optimize the
common case. SCEV's trip count computation for exits controlled by
'or' expressions is now analagous to the trip count computation for
loops with multiple exits. I had already fixed the multiple exit case
to be conservative.

llvm-svn: 182989

llvm-svn: 182988

[analyzer; new edges] in splitBranchConditionEdges() do not check that predecessor edge has source in the same lexical scope as the target branch.

Fixes <rdar://problem/14031292>.

llvm-svn: 182987

llvm-svn: 182986

llvm-svn: 182985

Patch by Jyun-Yan You.

llvm-svn: 182984

initialization. Previously we would incorrectly require an extra set of braces
around such initializers.

llvm-svn: 182983

llvm-svn: 182982

The new advanced option ensures ccc-analyze is used even when better
interposition methods are available.

llvm-svn: 182981

llvm-svn: 182980

llvm-svn: 182979

Making sure that I get my English right by saying “0 bytes” instead

llvm-svn: 182978

command script import now does reloads - for real
If you invoke command script import foo and it detects that foo has already been imported, it will
 - invoke reload(foo) to reload the module in Python
 - re-invoke foo.__lldb_init_module
 This second step is necessary to ensure that LLDB does not keep cached copies of any formatter, command, ... that the module is providing

Usual caveats with Python imports persist. Among these:
 - if you have objects lurking around, reloading the module won't magically update them to reflect changes
 - if module A imports module B, reloading A won't reload B
These are Python-specific issues independent of LLDB that would require more extensive design work

The --allow-reload (-r) option is maintained for compatibility with existing scripts, but is clearly documented as redundant - reloading is always enabled whether you use it or not

llvm-svn: 182977

insertelement instructions.

llvm-svn: 182976

Inconsistent (and wrong) sort order on non-Windows.

llvm-svn: 182975

In a certain code-path we were not deserializing an anonymous field initializer correctly,
leading to a crash when trying to IRGen it.

This is a simpler version of a patch by Yunzhong Gao!

llvm-svn: 182974