[PATCH] D15120: Add support for __float128 type to be used by targets that support it

[John McCall via cfe-commits]

rjmccall added inline comments.

================
Comment at: include/clang/Basic/TargetInfo.h:385
@@ +384,3 @@
+  unsigned getFloat128Width() const { return Float128Width; }
+  unsigned getFloat128Align() const { return Float128Align; }
+  const llvm::fltSemantics &getFloat128Format() const {
----------------
I think you can safely have this method hard-code the size, though. :)

================
Comment at: lib/AST/ASTContext.cpp:4594
@@ -4592,1 +4593,3 @@
+  case BuiltinType::Float128:
+    return Float128Rank;
   }
----------------
Follow the same code styling as above, please.

================
Comment at: lib/AST/ASTContext.cpp:4611
@@ -4607,2 +4610,3 @@
     case LongDoubleRank: return LongDoubleComplexTy;
+    case Float128Rank: return Float128ComplexTy;
     }
----------------
Indentation.

================
Comment at: lib/AST/ASTContext.cpp:4635
@@ +4634,3 @@
+  // If the two sides have Float128Rank and LongDoubleRank and the two types
+  // have the same representation on this platform, they have equal rank.
+  if ((LHSR == LongDoubleRank && RHSR == Float128Rank) ||
----------------
This is a really bad language rule with nasty implications for a lot of code.  Is there a really urgent need to emulate some other compiler bug-for-bug here?

It's okay for there to a formal rank difference even when types have the same representation — that's basically always true for the integer types — so unless there's a very specific and very good reason not to, let's just use the rule that float128 has higher rank than long double.


Repository:
  rL LLVM

http://reviews.llvm.org/D15120