This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> Peeking at the implementation of the expand_complex_division() function
> inside tree-complex.c I have compared the conditions for satisfying  
> the -fcx-limited-range and flag_isoc99
> condition. And thus I have some questions about the logics of it.
> In esp. the following lines (starting at 1222 inside the file):
> IN A ROW. I guess it should be a return statement instead. Much like  
> in the case
> of the multiply by intrinsic function. That's suspicious.

The break gets out of the inner switch statement and right after
that is a return and not out of the if.

> 	      break;
> 	    }
> 	  /* FALLTHRU */
> ==================
> The intrinsic function got expanded...
> 	case 1:
> ==================
> And now we are expanding the supposedly a bit less precise version of  
> the division
> directly behind it? This doesn't to be the same kind of "overflow  
> robustness logic"
> as in the case of multiplication.

The fall through is for non fp complex types, yes they exist in GCC
and in GNU C.

> Thus my question to whoever looked at this code close enough is:
> 1. Is the FALLTHRU really OK?

yes, see above. Plus the fall through is only for non fp types.

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

Andrew Pinski

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]