This header is private and shouldn't be used by clients.

llvm-svn: 149496

llvm-svn: 149495

This is a mess. According to the C++11 standard, pointer subtraction only has
undefined behavior if the difference of the array indices does not fit into a
ptrdiff_t.

However, common implementations effectively perform a char* subtraction first,
and then divide the result by the element size, which can cause overflows in
some cases. Those cases are not considered to be undefined behavior by this
change; perhaps they should be.

llvm-svn: 149490

The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods than SwitchInst ones (TerminatorInst or may be User). After this patch we can reorganize SwitchInst operands and successors as we want.

What was done:

1. Changed semantics of index inside the getCaseValue method:
getCaseValue(0) means "get first case", not a condition. Use getCondition() if you want to resolve the condition. I propose don't mix SwitchInst case indexing with low level indexing (TI successors indexing, User's operands indexing), since it may be dangerous.
2. By the same reason findCaseValue(ConstantInt*) returns actual number of case value. 0 means first case, not default. If there is no case with given value, ErrorIndex will returned.
3. Added getCaseSuccessor method. I propose to avoid usage of TerminatorInst::getSuccessor if you want to resolve case successor BB. Use getCaseSuccessor instead, since internal SwitchInst organization of operands/successors is hidden and may be changed in any moment.
4. Added resolveSuccessorIndex and resolveCaseIndex. The main purpose of these methods is to see how case successors are really mapped in TerminatorInst.
4.1 "resolveSuccessorIndex" was created if you need to level down from SwitchInst to TerminatorInst. It returns TerminatorInst's successor index for given case successor.
4.2 "resolveCaseIndex" converts low level successors index to case index that curresponds to the given successor.

Note: There are also related compatability fix patches for dragonegg, klee, llvm-gcc-4.0, llvm-gcc-4.2, safecode, clang.
llvm-svn: 149482

commit 149470. This fixes test/CodeGen/PR3589-freestanding-libcalls.c.

Original log:

    ConstantArray::get() (for strings) is going away, use
    ConstantDataArray::getString instead.

    Many instances of ConstantArray::get() could be moved to
    use more efficient ConstantDataArray methods that avoid a ton
    of intermediate Constant*'s for each element (e.g.
    GetConstantArrayFromStringLiteral).  I don't plan on doing this
    in the short-term though.

llvm-svn: 149477

llvm-svn: 149476

instead of the entire class definition.

llvm-svn: 149474

llvm-svn: 149473

type, be sure to add the qualifier for the enumeration type.

llvm-svn: 149471

a literal type. Disallow it as the return type of a constexpr function
declaration.

llvm-svn: 149469

llvm-svn: 149467

llvm-svn: 149463

  - Actually building the var -> capture mapping properly (there was an off-by-one error)
  - Keeping track of the source location of each capture
  - Minor QoI improvements, e.g, highlighing the prior capture if
  there are multiple captures, pointing at the variable declaration we
  found if we reject it.

As part of this, add standard citations for the various semantic
checks we perform, and note where we're not performing those checks as
we should.

llvm-svn: 149462

Fixes PR11847. Patch from Jason Haslam!

llvm-svn: 149460

llvm-svn: 149458

I removed support for "*-darwin*-iphoneos" triples, since we now have
iOS listed as a separate OS in the triples.

llvm-svn: 149455

Check if the triple OS is IOS instead of checking for arm/thumb architectures
and check that before calling isMacOSXVersionLT.

llvm-svn: 149454

llvm-svn: 149451

fixed in r149440.

llvm-svn: 149450

CFBridgingRetain/CFBridgingRelease calls instead
of __bridge_retained/__bridge_transfer casts as preferred
way of moving cf objects to arc land. // rdar://10207950

llvm-svn: 149449

isn't, but this is just a (reported) defect in the wording.

llvm-svn: 149448

llvm-svn: 149441

llvm-svn: 149440

llvm-svn: 149439

explicit type cast. // rdar://10521744

llvm-svn: 149437

cancel out each other. Leave it alone so users can take a look
(unmigrated code forces error diagnostic). // rdar://10521744

llvm-svn: 149435

builds, and bring mm_alloc.h into the fold. Start playing some tricks
with these builtin modules to mirror the include_next tricks that the
headers already perform.

llvm-svn: 149434

llvm-svn: 149424

The Darwin toolchain constructor was assuming that all Darwin triples would
have an OS string starting with "darwin".  Triples starting with "macosx"
would misinterpret the version number, and "ios" triples would completely
miss the version number (or worse) because the OS name is not 6 characters
long.  We lose some sanity checking of triple strings here, since the
Triple.getOSVersion function doesn't do all the checking that the previous
code did, but this still seems like a step in the right direction.

llvm-svn: 149422

(Since this is syntax only, might be a good candidate for turning into a
compiler warning.)

llvm-svn: 149407

replacements for 'starcat/strcpy' instead of 'strncat/strncpy'.

llvm-svn: 149406

llvm-svn: 149405

Revert r149359.  This was a hack to a problem with an easy workaround, and it doesn't feel like general solution.

llvm-svn: 149404

A separate unreachable message will make it easier to debug if either of the
unreachables is reached.

llvm-svn: 149402

Patch by Niels Grewe!

llvm-svn: 149401

__has_builtin

in an empty file, as we were overwriting the EOF token.  Overwriting an arbitrary token
never seems like a good idea in the error case.  This fixes a bug reported on the GCC
list :)

llvm-svn: 149397

llvm-svn: 149394

This fixes the case where Clang would output:
 error: format specifies type 'wchar_t *' (aka 'wchar_t *')

ArgTypeResult::getRepresentativeTypeName needs to take into account
that wchar_t can be a built-in type (as opposed to in C, where it is a
typedef).

llvm-svn: 149387

llvm-svn: 149385

llvm-svn: 149377