This is the mail archive of the gcc@gcc.gnu.org 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]

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


case PAIR (ONLY_REAL, VARYING):
case PAIR (ONLY_IMAG, VARYING):
case PAIR (VARYING, VARYING):
switch (flag_complex_method)
{
case 0:
==================
This is the "quick and don't care about overflow case". This seems just fine.


	  /* straightforward implementation of complex divide acceptable.  */
	  expand_complex_div_straight (bsi, inner_type, ar, ai, br, bi, code);
	  break;

case 2:
==================
This is supposed to be the ISO C99 conforming full overflow robust case.
Fine.
if (SCALAR_FLOAT_TYPE_P (inner_type))
{
expand_complex_libcall (bsi, ar, ai, br, bi, code);
==================
However here the break is causing update_complex_assignment() to be called TWICE
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.


	      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.


	  /* wide ranges of inputs must work for complex divide.  */
	  expand_complex_div_wide (bsi, inner_type, ar, ai, br, bi, code);
	  break;

	default:
	  gcc_unreachable ();
	}
      return;

    default:
      gcc_unreachable ();

Thus my question to whoever looked at this code close enough is:

1. Is the FALLTHRU really OK?
2. Shouldn't the logic when to decide which kind of implementation to take
not look a bit more like in the multiplication case?


Marcin Dalecki



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