I see the same issue with decimal long double constants.

I can reproduce this with any long-double constant. This fails:
const long double v = 0.0L;
int main()
{
	return 0;
}
clang: /src/llvm-trunk-dev-q/lib/Support/APFloat.cpp:121: void assertArithmeticOK(const llvm::fltSemantics&): Assertion `semantics.arithmeticOK && "Compile-time arithmetic does not support these semantics"' failed.
...
1.	ld.cpp:1:23: current parser token '0.0L'

A backtrace of the problem shows:
(gdb) up
#3  0x00000000028758d1 in assertArithmeticOK (semantics=...) at /src/llvm-trunk/lib/Support/APFloat.cpp:120
120	  assert(semantics.arithmeticOK &&
(gdb) up
#4  0x0000000002875c79 in llvm::APFloat::APFloat (this=0x7fffffff9390, ourSemantics=...)
    at /src/llvm-trunk/lib/Support/APFloat.cpp:741
741	  assertArithmeticOK(ourSemantics);
(gdb) list
736	  significandParts()[0] = value;
737	  normalize(rmNearestTiesToEven, lfExactlyZero);
738	}
739	
740	APFloat::APFloat(const fltSemantics &ourSemantics) : exponent2(0), sign2(0) {
741	  assertArithmeticOK(ourSemantics);
742	  initialize(&ourSemantics);
743	  category = fcZero;
744	  sign = false;
745	}
(gdb) up
#5  0x0000000000e0c18f in clang::Sema::ActOnNumericConstant (this=0x37da7a0, Tok=...)
    at /src/llvm-trunk/tools/clang/lib/Sema/SemaExpr.cpp:2428
2428	    APFloat Val(Format);
(gdb) list
2423	      Ty = Context.LongDoubleTy;
2424	
2425	    const llvm::fltSemantics &Format = Context.getFloatTypeSemantics(Ty);
2426	
2427	    using llvm::APFloat;
2428	    APFloat Val(Format);
2429	
2430	    APFloat::opStatus result = Literal.GetFloatValue(Val);
2431	
2432	    // Overflow is always an error, but underflow is only an error if

So the "problem" is that the APFloat constructor calls assertArithmeticOK which will fail for PPCDoubleDouble values. Why is it doing this?

The problem was introduced in r149121, and this problem was known at the time:
see: http://llvm.org/bugs/show_bug.cgi?id=11867

Yep, but it isn't a clang bug.  It's an llvm bug.  The PPC encoding just isn't implemented in llvm yet.

I now see this issue on powerpc-darwin8, bug 12444.  (This prevents me from compiling hello-world.)
I'm willing to help test if any patches are posted.

Is there any chance of this being done for 3.1?

(In reply to comment #7)
> Is there any chance of this being done for 3.1?

Unfortunately, I don't think so. I've started working on a fix, but it is not ready yet. For now, I'd recommend locally applying:

diff --git a/lib/Support/APFloat.cpp b/lib/Support/APFloat.cpp
index 409d4fb..5141125 100644
--- a/lib/Support/APFloat.cpp
+++ b/lib/Support/APFloat.cpp
@@ -61,7 +61,8 @@ namespace llvm {
   // The PowerPC format consists of two doubles.  It does not map cleanly
   // onto the usual format above.  For now only storage of constants of
   // this type is supported, no arithmetic.
-  const fltSemantics APFloat::PPCDoubleDouble = { 1023, -1022, 106, false };
+  // FIXME: arithmeticOK should really be false here...
+  const fltSemantics APFloat::PPCDoubleDouble = { 1023, -1022, 106, true };
 
   /* A tight upper bound on number of parts required to hold the value
      pow(5, power) is

This will allow parsing to not crash, but it will not really be correct, and long double codegen is still also not quite right.

(In reply to comment #8)
> (In reply to comment #7)
> Unfortunately, I don't think so. I've started working on a fix, but it is not
> ready yet. For now, I'd recommend locally applying:
> 
> This will allow parsing to not crash, but it will not really be correct, and
> long double codegen is still also not quite right.

Thanks, Hal.  Just having it not crash is valuable.  I do understand that it's not complete, but I don't plan to exercise much long double code myself.

What's the status of this after Ulrich Weigand's recent commits (ca. r166951)?

(In reply to comment #10)
> What's the status of this after Ulrich Weigand's recent commits (ca. r166951)?

Thanks for pointing this out... this is now resolved.

MacPorts' llvm-3.2 port is at r166880.  I'm testing an update to r167157 right now and will probably commit it in the next day or so to allow MacPorts users to easily test this.