[llvm-commits] [PATCH] llvm-stress fixes

[Hal Finkel]

On Mon, 16 Apr 2012 22:58:04 +0200
Gabor Greif <gabor at mac.com> wrote:

> Hal wrote:
> 
> > The current situation is not great, support for ppc128 in APFloat is
> > currently broken, and while fixing it is on my TODO list, I have not
> > really worked on it yet.
> 
> Something changed lately, as clang is ICEing on me when encountering  
> a long double literal.
> I am targetting PowerPC.

You essentially have two options. First, are you targeting PPC on Linux
(where long double is now *normally* ppc128) or something else (where
long double == double).

If you really need a ppc128-targeting build, then for now, you'll need
to locally disable the assertions this way:
===================================================================
--- lib/Support/APFloat.cpp	(revision 154802)
+++ lib/Support/APFloat.cpp	(working copy)
@@ -61,7 +61,7 @@
   // 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 };
+  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 is what I use for now. The produced code is wrong (so don't
actually do any long double computations), and I'm working on redoing
the support so that it will all work again :) -- I'll let you know as
soon as I have something.

 -Hal

> 
> >
> > If you edit APFloat.cpp to disable the relevant asserts then you can
> > compile codes with long doubles in them (which is important for C++
> 
> Yes, I had to manually comment out an assertion in APFloat.cpp, to  
> avoid the ICEs.
> 
> > codes that #include <complex>, for example), but any code that  
> > actually
> > uses long doubles will most likely output the wrong answer.
> > Therefore, so long as some skeleton support exists, then there is
> > no regression in
> > practice.
> 
> My sources do not actually resort to long doubles, but the <limits>  
> header in our g++ installation does
> have a specialization for 'long double' with literals in it. This  
> seems to trigger the issue.
> 
> >
> > I would be happy to move the relevant code into the frontend, but  
> > while
> > I imagine that in some ways this is very similar to how _Complex  
> > double
> > is handled, any assistance would be appreciated.
> 
> I gather that once the frontend is fixed the assert won't trigger
> any more?
> 
> Cheers,
> 
>      Gabor
> 
> >
> > Thanks again,
> > Hal
> 
> 



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory