[PATCH]: Fix PR middle-end/30789, complex math folding via MPC

Kaveh R. Ghazi ghazi@caip.rutgers.edu
Fri Aug 14 16:53:00 GMT 2009


From: "Joseph S. Myers" <joseph@codesourcery.com>

> On Fri, 14 Aug 2009, Kaveh R. GHAZI wrote:
>
>> The Annex G special cases only occur in cases where NaN is returned. 
>> Since
>> GCC's MPC infrastructure already backs out when encountering NaN values,
>> using MPC here means folding doesn't occur and the correct Annex G values
>> are calculated by libgcc at runtime.
>
> These cases still need to work in static initializers, so you may need to
> avoid the MPC infrastructure backing out when evaluating static
> initializers, and add tests of them to your testcase.
>
>> +  /* This becomes (NaN + iInf).  */
>> +#define VAL1 ((_Complex double)__builtin_inf() * 1i)
>> +
>> +  /* Test some C99 Annex G special cases.  */
>> +  TEST_ONE_PART_INF ((VAL1) * (VAL1));
>> +  TEST_ONE_PART_INF ((_Complex double)1 / (_Complex double)0);
>> +  TEST_ONE_PART_INF ((VAL1) / (_Complex double)1);
>
> I don't see a test of the ((_Complex double) 1 / (VAL1)) example I gave
> (that should produce a zero).

Thanks for catching these, I'll address these in a followup patch.  (The new 
behavior is guarded by HAVE_mpc so no one is affected right now.)




More information about the Gcc-patches mailing list