https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107294
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2022-10-17
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is that the fortran frontend produces
complex(kind=4) __result_csmul;
__result_csmul = COMPLEX_EXPR <a, 0.0> * b;
return __result_csmul;
while the C frontend does
return COMPLEX_EXPR <SAVE_EXPR <a> * REALPART_EXPR <SAVE_EXPR <b>>, SAVE_EXPR
<a> * IMAGPART_EXPR <SAVE_EXPR <b>>>;
the fortran IL then gets optimized to
<bb 2> [local count: 1073741824]:
b$real_6 = REALPART_EXPR <b_4(D)>;
b$imag_7 = IMAGPART_EXPR <b_4(D)>;
_8 = a_3(D) * b$real_6;
_9 = b$imag_7 * 0.0;
_10 = a_3(D) * b$imag_7;
_11 = b$real_6 * 0.0;
_12 = _8 - _9;
_13 = _10 + _11;
_2 = COMPLEX_EXPR <_12, _13>;
return _2;
and here we have to stop because with singed zeros the multiply by zero
is ambiguous and the resulting sign important(?). With -fno-signed-zeros
the optimization result is the same but really the C frontend
interprets scalar * complex multiplication differently here.
Not sure who is correct, or if both are and we can optimize the multiply
by zero here (maybe in the context of a - b * 0.0 and a + b * 0.0).
It looks like the C17 standard in the G.5.1 annex gives us leeway to
implement multiplication in the pre-simplified form we do. Somebody
would have to check the Fortran standard how to treat this case.
