Chandler Carruth 6f78fbbc63 Switch the empty and tombstone key enumerators to not have explicit ... values -- that's not required to fix the bug that was cropping up, and the values selected made the enumeration's underlying type signed and introduced some warnings. This fixes the -Werror build. The underlying issue here was that the DenseMapInfo was casting values completely outside the range of the underlying storage of the enumeration to the enumeration's type. GCC went and "optimized" that into infloops and other misbehavior. By providing designated special values for these keys in the dense map, we ensure they are indeed representable and that they won't be used for anything else. It might be better to reuse None for the empty key and have the tombstone share the value of the sentinel enumerator, but honestly having 2 extra enumerators seemed not to matter and this seems a bit simpler. I'll let Bill shuffle this around (or ask me to shuffle it around) if he prefers it to look a different way. I also made the switch a bit more clear (and produce a better assert) that the enumerators are *never* going to show up and are errors if they do. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171614 91177308-0d34-0410-b5e6-96231b3b80d8		2013-01-05 08:47:26 +00:00
..
Argument.h
Attributes.h	Switch the empty and tombstone key enumerators to not have explicit	2013-01-05 08:47:26 +00:00
BasicBlock.h
CallingConv.h
CMakeLists.txt
Constant.h
Constants.h
DataLayout.h
DerivedTypes.h
Function.h
GlobalAlias.h
GlobalValue.h
GlobalVariable.h
InlineAsm.h
InstrTypes.h
Instruction.def
Instruction.h
Instructions.h
IntrinsicInst.h
Intrinsics.h
Intrinsics.td
IntrinsicsARM.td
IntrinsicsHexagon.td
IntrinsicsMips.td
IntrinsicsNVVM.td
IntrinsicsPowerPC.td
IntrinsicsR600.td
IntrinsicsX86.td
IntrinsicsXCore.td
IRBuilder.h
LLVMContext.h
MDBuilder.h
Metadata.h
Module.h
OperandTraits.h
Operator.h
SymbolTableListTraits.h
Type.h
TypeBuilder.h
Use.h
User.h
Value.h
ValueSymbolTable.h