[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