getSymbolWithGlobalValueBase use is to create a name of a new symbol based
on the name of an existing GV. Assert that and then remove the last call
to pass true to isImplicitlyPrivate.

This gives the mangler API a 1:1 mapping from GV to names, which is what we
need to drop the mangler dependency on the target (and use an extended
datalayout instead).

llvm-svn: 196472

This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.

llvm-svn: 196471

given

declare void @llvm.memset.p0i8.i32(i8* nocapture, i8, i32, i32, i1)
declare void @foo()
define void @bar() {
  call void @foo()
  call void @llvm.memset.p0i8.i32(i8* null, i8 0, i32 188, i32 1, i1 false)
  ret void
}

We used to produce

L_foo$stub:
        .indirect_symbol        _foo
        .ascii  "\364\364\364\364\364"

_memset$stub:
        .indirect_symbol        _memset
        .ascii  "\364\364\364\364\364"

We not produce a private stub for memset too.

Stubs are not needed with recent linkers, but we still produce them for darwin8.

Thanks to David Fang for confirming that gcc used to do this too.

llvm-svn: 196468

llvm-svn: 196467

This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities in nearby lines.

llvm-svn: 196466

llvm-svn: 196465

name from the enclosing namespace set if the name is specified as a
qualified-id.

llvm-svn: 196464

llvm-svn: 196463

This just extends the existing hack. It should be enough to get a reproducible bootstrap
on 32 bits.

I will open a bug to track getting a real fix for this.

llvm-svn: 196462

A raw lexer in its initial state is guaranteed to be on line number one.

llvm-svn: 196461

Did you expect to break DOS driveletter?

llvm-svn: 196460

llvm-svn: 196459

Emitting idata atoms to their own section would make debugging easier.
The Windows loader do not really care about whether the DLL import table is
in .rdata or its own .idata section, so there is no change in functionality.

llvm-svn: 196458

llvm-svn: 196457

llvm-svn: 196456

Use FunctionTypeUnwrapper like we do in AttributedType to try to keep
some sugar.  We can actually do one better here in the future by
avoiding the AdjustedType node altogether when no sugar would be lost.

llvm-svn: 196455

For an init capture, process the initialization expression
right away.  For lambda init-captures such as the following:
const int x = 10;
 auto L = [i = x+1](int a) {
   return [j = x+2,
          &k = x](char b) { };
 };
keep in mind that each lambda init-capture has to have:
 - its initialization expression executed in the context
   of the enclosing/parent decl-context.
 - but the variable itself has to be 'injected' into the
   decl-context of its lambda's call-operator (which has
   not yet been created).
Each init-expression is a full-expression that has to get
Sema-analyzed (for capturing etc.) before its lambda's
call-operator's decl-context, scope & scopeinfo are pushed on their
respective stacks.  Thus if any variable is odr-used in the init-capture
it will correctly get captured in the enclosing lambda, if one exists.
The init-variables above are created later once the lambdascope and
call-operators decl-context is pushed onto its respective stack.

Since the lambda init-capture's initializer expression occurs in the
context of the enclosing function or lambda, therefore we can not wait
till a lambda scope has been pushed on before deciding whether the
variable needs to be captured.  We also need to process all
lvalue-to-rvalue conversions and discarded-value conversions,
so that we can avoid capturing certain constant variables.
For e.g.,
 void test() {
  const int x = 10;
  auto L = [&z = x](char a) { <-- don't capture by the current lambda
    return [y = x](int i) { <-- don't capture by enclosing lambda
         return y;
    }
  };
If x was not const, the second use would require 'L' to capture, and
that would be an error.
Make sure TranformLambdaExpr is also aware of this.

Patch approved by Richard (Thanks!!) 
http://llvm-reviews.chandlerc.com/D2092

llvm-svn: 196454

We would skip until the next comma, hoping good things whould lie there,
however this would fail when we have such things as this:

struct A {};
template <typename>
struct D;
template <>
struct D<C> : B, A::D;

Once this happens, we would believe that D with a nested namespace
specifier of A was a variable that was being declared. We would go on
to complain that there was an extraneous 'template <>' on their variable
declaration.

Crashes would happen when 'A' gets defined as 'enum class A {}' as
various asserts would fire.

Instead, we should skip up until the semicolon if we see that we are in
the middle of a definition and the current token is a ':'

This fixes PR17084.

llvm-svn: 196453

This is not being used yet, and in practice, more refactoring would be required to make this fully practical
In practice, the way this should work is that CalculateNumChildren(), GetChildAtIndex(), GetIndexOfChildWithName() and MightHaveChildren() should all default to failure values when m_valid == false. Update() should be the only function actually setting/clearing the flag upon inspecting the backend ValueObject, if it determines it to be in an incongruent state
Given refactoring of the FrontEnd APIs, this work could be automatically performed without the individual providers having to replicate this logic
The way this works now is that each front end picks one or more “key ivars” and keys off those to detect invalidity
This is a baby step 0 to a better world

llvm-svn: 196452

Summary:
In general, this type node can be used to represent any type adjustment
that occurs implicitly without losing type sugar.  The immediate use of
this is to adjust the calling conventions of member function pointer
types without breaking template instantiation.

Fixes PR17996.

Reviewers: rsmith

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

llvm-svn: 196451

The CodeGenOptions are not used for ABI type selection, so we will just
create one with the default constructor (there is a FloatABI option in
CodeGenOptions that is passed on to LLVM, but not used in Clang for LLVM
IR type generation).

We can use the DiagnosticsEngine on the ASTContext rather than making a
client pass one in explicitly.

llvm-svn: 196450

llvm-svn: 196449

Most people are using MSVC 2012, which lacks the <initializer_list>
header.  MSVC 2013 shipped with that header, but it has not yet been
tested.  If clang works with the 2013 header, then we can enable this by
checking the value of _MSC_VER.

llvm-svn: 196448

llvm-svn: 196447

DIEs already contain references directly to their DIEAbbrev, use that
instead of looking it up based on index.

llvm-svn: 196446

llvm-svn: 196445

changes.

llvm-svn: 196444

nested-name-specifier, rather than crashing. (In fact, reject all
literal-operator-ids that have a non-namespace nested-name-specifier). The
grammar doesn't allow these in some cases, and in other cases does allow them
but instantiation will always fail.

llvm-svn: 196443

llvm-svn: 196442

values with the correct behavior.

llvm-svn: 196441

ELF_Other_Weakref and ELF_Other_ThumbFunc seems to be LLVM
internal ELF symbol flags.  These should not be emitted to
object file.

This commit defines ELF_STO_Shift for the target-defined
flags for st_other, and increase the value of
ELF_Other_Shift to 16.

llvm-svn: 196440

ScalarSafeChars array in Output::scalarString (See YAMLTraits.cpp line 554 as
of r196428), this test will fail: The path will be single quoted to preserve
the 'unsafe' characters, which doesn't match the expected (unquoted) output.
Notionally "unsafe" characters include fairly innocuous ones like the '+'
symbol (I don't know enough YAML to be sure, but I suspect '+' doesn't really
need to be quoted).

I have added some sed lines to strip leading spaces, and leading and trailing
single quote (') characters from the path. That should make this test slightly
more robust.

If possible, this test should be rewritten to use FileCheck, rather than
diffing against expected output - the latter is likely to brittle, and require
further sed goop in the future.

llvm-svn: 196439

We were previously not adding fast-math flags through CreateBinOp()
when it happened to be making a floating point binary operator. This
patch updates it to do so similarly to directly calling CreateF*().

llvm-svn: 196438

llvm-svn: 196437

llvm-svn: 196436

Patch by Aleksey Bader.

llvm-svn: 196435

llvm-svn: 196434

Code review feedback on r196394 by Paul Robinson.

llvm-svn: 196433

Where it would use a scattered relocation entry but falls back to a
normal relocation entry because the FixupOffset is more than 24-bits.

The bug is in the X86MachObjectWriter::RecordScatteredRelocation() where
it changes reference parameter FixedValue but then returns false to indicate
it did not create a scattered relocation entry.  The fix is simply to save the
original value of the parameter FixedValue at the start of the method and
restore it if we are returning false in that case.

rdar://15526046

llvm-svn: 196432

llvm-svn: 196431