This is the mail archive of the
mailing list for the GCC project.
Suspicious expand_complex_division() in tree-comlpex.c
- From: Marcin Dalecki <martin at dalecki dot de>
- To: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Fri, 5 Jan 2007 08:27:38 +0100
- Subject: 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):
This is the "quick and don't care about overflow case". This seems
/* straightforward implementation of complex divide acceptable. */
expand_complex_div_straight (bsi, inner_type, ar, ai, br, bi, code);
This is supposed to be the ISO C99 conforming full overflow robust case.
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
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.
/* FALLTHRU */
The intrinsic function got expanded...
And now we are expanding the supposedly a bit less precise version of
directly behind it? This doesn't to be the same kind of "overflow
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);
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
not look a bit more like in the multiplication case?