>
>
>
> Yes I see now... a quite complicated way to express the choice logic:
>
> 1. if -fcx-limited-range is set go straight for the quick overflowing
> version.
> 2. be strict in case of ISO C99.
> 3. handle floaing poing divisions more precisely then multiplications
> else.
if you look at where flag_complex_method is defined in toplev.c:
there is a nice comment:
/* 0 means straightforward implementation of complex divide acceptable.
1 means wide ranges of inputs must work for complex divide.
2 means C99-like requirements for complex multiply and divide. */
>
> >> 2. Shouldn't the logic when to decide which kind of implementation to
> >> take
> >> not look a bit more like in the multiplication case?
> >
> > It is the same in general anyways but division is the one that is
> > different between flag_complex_method==0 and flag_complex_method==1.
>
> OK. This confirms that the three state flag_complex_method could be
> eliminated, and fcx_limited_range used directly instead.
> (My final goal is of course something in the way of #pragma STDC
> CX_LIMITED_RANGE)...
No, they cannot.
We default to flag_complex_method == 1.
Then with -fcx-limited-range we get = 0:
/* With -fcx-limited-range, we do cheap and quick complex arithmetic. */
if (flag_cx_limited_range)
flag_complex_method = 0;
And with -std=c99, we get 2:
/* C99 requires special handling of complex multiplication and division;
-ffast-math and -fcx-limited-range are handled in process_options. */
if (flag_isoc99)
flag_complex_method = 2;
I don't see why you think we can elimitate the three state variable.
We allow complex types in GNU C89. Plus other front-ends use complex types
so getting rid of the three state variable will cause regressions in
say fortran.
-- Pinski
