"On SPU, variables in the .bss section that are allocated with the .lcomm directive are not aligned on 16 byte boundaries. This causes misaligned loads, as the generated assembly assumes this "default" alignment.

this patch disables .lcomm in favour of '.local .comm'

Patch by Kalle Raisklia!

llvm-svn: 100875

llvm-svn: 100874

type..." with "initializing <type> with an expression of type...",
which reads better. Thanks to John for the improved wording.

llvm-svn: 100873

the implicit template instantiations we need to perform. Otherwise, we
end up erroneously diagnosing static functions as used if they were
only used within an implicit template instantiation. Fixes a bunch of
spurious failures when building Clang with Clang.

llvm-svn: 100872

type isn't dependent.  Fixes rdar://problem/7838962.

llvm-svn: 100871

attr constructor or destructor.  Patch by Jean-Daniel Dupas!

llvm-svn: 100870

llvm-svn: 100869

llvm-svn: 100867

precompiled headers and/or when reading the contents of the file into
memory. These checks seem to be causing spurious regression-test
failures on Windows.

llvm-svn: 100866

for objc.

llvm-svn: 100865

llvm-svn: 100864

llvm-svn: 100862

llvm-svn: 100860

llvm-svn: 100859

llvm-svn: 100858

llvm-svn: 100856

llvm-svn: 100852

llvm-svn: 100850

llvm-svn: 100849

llvm-svn: 100848

llvm-svn: 100846

a separate function.

llvm-svn: 100845

integrated into the llvm-mc testing tool.

llvm-svn: 100842

llvm-svn: 100841

be sent to LSR, which it isn't prepared to handle.

llvm-svn: 100839

llvm-svn: 100838

forced constant is changed to a constant, we would end
up adding the instruction to the wrong worklist, 
preventing it from being properly revisited.  This fixes
rdar://7832370

llvm-svn: 100837

valid instantiations.

llvm-svn: 100836

destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as

t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
      expected 'char *' [-pedantic]
  char *name = __func__;
        ^      ~~~~~~~~

We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:

t.c:2:9: warning: initializing 'char *' from an expression of type
      'char const [2]' discards qualifiers [-pedantic]
  char *name = __func__;
        ^      ~~~~~~~~

Fixes <rdar://problem/7447179>.

llvm-svn: 100832

state was being executed too lazily, and the LLVM
assembly syntax for the disassembler was not being
written into the proper disassembler state variable.

llvm-svn: 100830

inputs happen to negate each other.

llvm-svn: 100828

platforms (for this test).

llvm-svn: 100827

llvm-svn: 100825

llvm-svn: 100824

This is still not an ideal solution, but should disable the check for other
targets where the value of O_CREAT is different.

llvm-svn: 100818

llvm-svn: 100817

looking into an alternate fix right now.

llvm-svn: 100816

llvm-svn: 100815

warning. It's not harmful to have such pointless declarations, and GCC
does not diagnose this issue consistently.

llvm-svn: 100814

of c-style arguments. Completes radar 7445205.

llvm-svn: 100813