skip the x86_64 version for mingw32 and win32.

llvm-svn: 164977

  * Updates ReaderELF.cpp contentType method to match ELF.h's logic and now handle
    typeData
  * Add -arch to ldd-core testdriver
  * Add testcase to check typeData
  * Update others to stay in sync with this change.

llvm-svn: 164976

llvm-svn: 164975

The target backend can support data-in-code load commands even when
the assembler doesn't, or vice-versa. Allow targets to opt-in for
direct-to-object.

PR13973.

llvm-svn: 164974

llvm-svn: 164973

llvm-svn: 164972

llvm-svn: 164971

32bit and 64bit version of modern translator.
// rdar://12189793

llvm-svn: 164970

llvm-svn: 164969

Fix treatment of case which came up on std-proposals@: 'void' is permitted in core constant expressions, despite not being a literal type.

llvm-svn: 164968

representation. Fix crash if it appears in the return type of a member function
definition.

llvm-svn: 164967

llvm-svn: 164966

llvm-svn: 164965

llvm-svn: 164964

llvm-svn: 164961

By analogy with C structs, this seems to be legal, if probably discouraged.
It's only if the ivar is read from or written to that there's a problem.
Running a program that gets the "address" of an instance variable does in
fact return the offset when the base "object" is nil.

This isn't a full revert because r164442 includes some diagnostic tweaks
as well; those have been kept.

This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4.

llvm-svn: 164960

This seems to be legal according to C11 6.5.3.2.

No functionality change.

llvm-svn: 164959

The original intent of this commit was to catch potential null dereferences
early, but it breaks the common "home-grown offsetof" idiom (PR13927):

 (((struct Foo *)0)->member - ((struct foo *)0))

As it turns out, this appears to be legal in C, per a footnote in
C11 6.5.3.2: "Thus, &*E is equivalent to E (even if E is a null pointer)".
In C++ this issue is still open:
  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232

We'll just have to make sure we have good path notes in the future.

This reverts r164441 / 9be016dcd1ca3986873a7b66bd4bc027309ceb59.

llvm-svn: 164958

care of comments by Dimitri and Doug.

llvm-svn: 164957

The Apple buildbots have been modified not to pass --target,
so they shouldn't choke on a default program prefix anymore.

Patch by Rick Foos!

llvm-svn: 164956

string in the config table so that it can be dumped as part of the 
config dumper.  Add a test to show that these options are sticking
and can be cross-checked using FileCheck.

llvm-svn: 164954

The format of this output is a WIP; largely I'm bringing it up now
for regression testing.  We can evolve the output format over time.

llvm-svn: 164953

This is related to but not blocked by <rdar://problem/12137950>
("Return-by-value structs do not have associated regions")

This reverts r164875 / 3278d41e17749dbedb204a81ef373499f10251d7.

llvm-svn: 164952

-Allow Sema to do more processing on the initial Expr before checking it.
-Remove the special conditions in HandleExpr()
-Move the code so that only one call site is needed.
-Removed the function from Sema and only call it locally.
-Warn on potentially evaluated reference variables, not just casts to r-values.
-Update tests.

llvm-svn: 164951

<rdar://problem/12406088> Fixing a crasher with adding a regex command, due to accessing a shared pointer without first checking for NULL

llvm-svn: 164950

llvm-svn: 164949

llvm-svn: 164948

It is possible and valid to have a state manager and associated objects
without having a SubEngine or checkers.

Patch by Olaf Krzikalla!

llvm-svn: 164947

- Update maximal stack alignment when stack arguments are prepared before a
  call.
- Test cases are enhanced to show it's not a Win32 specific issue but a generic
  one.

llvm-svn: 164946

Reduces runtime of i386-large-relocations.s by 10x in Release builds, even more
in Debug+Asserts builds.

llvm-svn: 164945

"#include <initializer_list>" is unavailable for whatever reason.

llvm-svn: 164944

Patch by Gábor Horváth.
Review: http://llvm-reviews.chandlerc.com/D46

llvm-svn: 164943

llvm-svn: 164940

is the second time I've moved this comment around...)

llvm-svn: 164939

llvm-svn: 164938

alignment requirements of the new alloca. As one consequence which was
reported as a bug by Duncan, we overaligned memcpy calls to ranges of
allocas after they were rewritten to types with lower alignment
requirements. Other consquences are possible, but I don't have any test
cases for them.

llvm-svn: 164937

llvm-svn: 164935

Fixes PR13985.

llvm-svn: 164934

could probably be factored still further to hoist this logic into
a generic helper, but currently I don't have particularly clean ideas
about how to handle that.

This at least allows us to drop custom load rewriting from the
speculation logic, which in turn allows the existing load rewriting
logic to fire. In theory, this could enable vector promotion or other
tricks after speculation occurs, but I've not dug into such issues. This
is primarily just cleaning up the factoring of the code and the
resulting logic.

llvm-svn: 164933

Lookup can nevertheless find them due to the serialized lookup table.
For instance when reading a template decl's templatedDecl, it will search for existing decls that it could be a redeclaration of, and find the half-read template decl.
Thus there is no point in asserting the names of decls.

llvm-svn: 164932