https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115827
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2026-02-13
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
The thing is that w/ -msoft-float we end up with
<bb 2> [local count: 1073741824]:
if (cond_5(D) != 0)
goto <bb 3>; [34.00%]
else
goto <bb 4>; [66.00%]
<bb 3> [local count: 365072224]:
REALPART_EXPR <<retval>> = 1.0e+0;
IMAGPART_EXPR <<retval>> = 0.0;
goto <bb 5>; [100.00%]
<bb 4> [local count: 708669600]:
REALPART_EXPR <<retval>> = f$real_9(D);
IMAGPART_EXPR <<retval>> = 0.0;
<bb 5> [local count: 1073741824]:
return <retval>;
and we then sink the common "stores", resulting in
<bb 4> [local count: 1073741824]:
# _11 = PHI <1.0e+0(2), f$real_9(D)(3)>
REALPART_EXPR <<retval>> = _11;
IMAGPART_EXPR <<retval>> = 0.0;
which then CCP happily optimizes to
<bb 4> [local count: 1073741824]:
REALPART_EXPR <<retval>> = 1.0e+0;
IMAGPART_EXPR <<retval>> = 0.0;
but without -msoft-float we end up with
<bb 2> [local count: 1073741824]:
if (cond_5(D) != 0)
goto <bb 4>; [34.00%]
else
goto <bb 3>; [66.00%]
<bb 3> [local count: 708669600]:
f_4 = COMPLEX_EXPR <f$real_7(D), 0.0>;
<bb 4> [local count: 1073741824]:
# _2 = PHI <__complex__ (1.0e+0, 0.0)(2), f_4(3)>
return _2;
instead. So there's a missed optimization in that CCP doesn't treat
COMPLEX_EXPR <f$real_7(D), 0.0> as possibly constant and mergeable
with the other PHI arg.
It's indeed the usual CCP induced false negative. This could be fixed
by avoiding the constants in the testcase, like doing
typedef _Complex float C;
C foo(int cond, float r)
{
C f;
__imag__ f = 0;
if (cond)
{
__real__ f = r;
return f;
}
return f; /* { dg-warning "may be used" "unconditional" } */
}