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
