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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
