Re: Suspicious expand_complex_division() in tree-comlpex.c

[Andrew Pinski <pinskia at physics dot uc dot edu>]

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