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

[Gabor Greif]

Am 16.04.2012 um 23:18 schrieb 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).

I am targeting PPC Linux (MontaVista, to be specific).

>
> 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.

Great, this is completely sufficient for the short term.

Thanks and cheers,

	Gabor


>
>  -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