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

1 files changed, 5 insertions, 3 deletions

diff --git a/lib/IR/Attributes.cpp b/lib/IR/Attributes.cpp
index 039e036..c0704dc 100644
--- a/lib/IR/Attributes.cpp
+++ b/lib/IR/Attributes.cpp
@@ -425,9 +425,11 @@ uint64_t AttributeImpl::getBitMask() const {
 
 uint64_t AttributeImpl::getAttrMask(Attribute::AttrKind Val) {
   switch (Val) {
-  case Attribute::EndAttrKinds:    break;
-  case Attribute::EmptyKey:        break;
-  case Attribute::TombstoneKey:    break;
+  case Attribute::EndAttrKinds:
+  case Attribute::AttrKindEmptyKey:
+  case Attribute::AttrKindTombstoneKey:
+    llvm_unreachable("Synthetic enumerators which should never get here");
+
   case Attribute::None:            return 0;
   case Attribute::ZExt:            return 1 << 0;
   case Attribute::SExt:            return 1 << 1;