For for-nodes that are translated to a set of vector lanes, we already know the
overall number of iterations. Calculating the upper bound is consequently not
necessary. This change removes the code for upper bound calculation, which was
probably copy/pasted from the code generation for the normal for-loop.

This issue was found by Sylvestre's scan-build server.

llvm-svn: 193925

llvm-svn: 193924

Flexible array members inherently index off of the end of their parent
type.

We shouldn't allow this type to be used as a base, virtual or otherwise,
because indexing off the end may find us inside of another base or the
derived types members.

llvm-svn: 193923

llvm-svn: 193922

llvm-svn: 193921

Flexible array members only work out if they are the last field of a
record, however virtual bases would give us many situations where the
flexible array member would overlap with the virtual base fields.

It is unlikely in the extreme that this behavior was intended by the
user so raise a diagnostic instead of accepting.  This is will not
reject conforming code because flexible array members are an extension
in C++ mode.

llvm-svn: 193920

The determination of which diagnostics would be issued for certain
anonymous unions started to get a little ridiculous.  Clean this up by
inverting the condition-tree's logic from dialect -> issue to
issue -> diagnostic.

As part of this cleanup, move ext_c99_flexible_array_member from
DiagnosticParseKinds.td to DiagnosticSemaKinds.td because it's driven by
Sema, not Parse.

Also, the liberty was taken to edit ext_c99_flexible_array_member to
match other, similar, diagnostics.

llvm-svn: 193919

The declaration of a flexible array member was correctly diagnosed as an
extension in C89 mode but not in C++.

llvm-svn: 193918

llvm-svn: 193917

llvm-svn: 193916

llvm-svn: 193915

llvm-svn: 193914

llvm-svn: 193913

There is still a long way to go for llvm-nm, but at least we now match
nm's letter output in the cases we test for.

llvm-svn: 193912

llvm-svn: 193911

These tests assume that the created objects are for x86_64. These tests
failed on non-x86_64 environments, such as 32 bit Windows.

llvm-svn: 193910

n_desc field in MachO string table was not initialized. On Unix,
test/darwin/hello-world.objtxt did not fail because I think an nlist object
is always allocated to a fresh heap initialized with zeros. On Windows,
uninitialized fields are filled with 0xCC when compiled with /GZ. Because
of that the test was failing on Windows.

llvm-svn: 193909

  - Don't seek "entry:" It dosen't appear with -Asserts.
  - Take care that Codegen'ed Instruction(s) wouldn't have name(s) in -Asserts.

llvm-svn: 193908

defines a protocol that all subclasses will implement.  StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.

Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.

This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone.  No new functionality is
added with this patch, no new subclasses of Frame exist yet.

I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.

<rdar://problem/15314068>

llvm-svn: 193907

specializations.  Also switch to -Wuninitialized for a test case that depended
on a warning firing in template specializations.

llvm-svn: 193906

On Windows, neither "(" nor ")" are shell special characters, so -\( is passed
as-is to LLD. Because of that this test was failing on Windows.

llvm-svn: 193905

This patch adds "-target x86_64" to the command line. Without this option,
a 32 bit object file would be created on 32 bit machine, resulting in test
failure.

llvm-svn: 193904

llvm-svn: 193903

llvm-svn: 193902

long in linux 64 is 64 bits but is always 32 bits on windows.  The lit test was modified 
to use long long instead of long and check for 64-bit mangling.

llvm-svn: 193901

- When selecting BLEND from vselect, the operands need swapping as due to the
  difference between vselect and SSE/AVX's BLEND insn

llvm-svn: 193900

Added -o option to llvm-cov. If no output file is specified, it defaults
to STDOUT.

llvm-svn: 193899

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

Clang was "improperly" over-aligning arrays with sizes are not a multiple of 
their alignment. 
This behavior was removed in microsoft 32 bit mode.

In addition, after examination of ASTContext::getTypeInfoImpl, a redundant code block in 
MicrosoftRecordLayoutBuilder::getAdjustedFieldInfo was deleted.

llvm-svn: 193898

llvm-svn: 193897

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

Adds a lang_c LinkageSpecDecl to lazily generated builtins. This enforces correct 
behavior for builtins in a variety of cases without special treatment elsewhere within 
the compiler (special treatment is removed by the patch). It also allows for C++ 
overloads of builtin functions, which Microsoft uses in their headers e.g. 
_InterlockedExchangeAdd is an extern C builtin for the long type but an inline wrapper 
for int type.

llvm-svn: 193896

llvm-svn: 193895

llvm-svn: 193894

... in case someone decides to -I/usr/include <rdar://problem/15235948>.

llvm-svn: 193893

I hit some problems with future work due to the member subprogram of
'a_b's type having a subprogram (an implicit default ctor, !52 in the
pre-commit source) with no name. Clang now generates a name for such a
function but in this case doesn't even emit debug info for it as it is
unused (Clang never emits the body of the ctor, instead just emitting
memset if needed).

llvm-svn: 193892

When the loop vectorizer was part of the SCC inliner pass manager gvn would
run after the loop vectorizer followed by instcombine. This way redundancy
(multiple uses) were removed and instcombine could perform scalarization on the
induction variables. Having moved the loop vectorizer to later we no longer run
any form of redundancy elimination before we perform instcombine. This caused
vectorized induction variables to survive that did not before.

On a recent iMac this helps linpack back from 6000Mflops to 7000Mflops.

This should also help lpbench and paq8p.

I ran a Release (without Asserts) build over the test-suite and did not see any
negative impact on compile time.

radar://15339680

llvm-svn: 193891

warning in template specializations.

llvm-svn: 193890

-fobjc-subscripting-legacy-runtime which is off 
by default and on only when using ObjectiveC
legacy runtime. Use this flag to allow
array and dictionary subscripting and disallow
objectiveC pointer arithmatic in ObjectiveC
legacy runtime. // rdar://15363492

llvm-svn: 193889

llvm-svn: 193888

llvm-svn: 193887

Bugs that would be caught by this assertion would also be caught by
RoundTripYAMLPass test. We've enabled the pass for PECOFF, so we can remove
this.

llvm-svn: 193886