https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111773
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-10-12
Status|UNCONFIRMED |ASSIGNED
Component|c++ |ipa
Ever confirmed|0 |1
CC| |hubicka at gcc dot gnu.org,
| |marxin at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Keywords| |wrong-code
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the second case I think we do something wrong. local-pure-const figures
operator new is 'noreturn':
Function is locally looping.
Function is locally throwing.
Function is locally malloc.
Function found to be noreturn: operator new
and fixup_cfg in turn turns main into
int main ()
{
int * D.3130;
int * p1;
int * _3(D);
<bb 2> :
operator new (4);
}
which would be fine I think. But then CDDCE decides
Eliminating unnecessary statements:
Deleting : operator new (4);
and we end up with
int main ()
{
int * D.3130;
int * p1;
int * _3(D);
<bb 2> :
}
and local-pure-const adds an unreachable:
local analysis of int main()/18
checking previously known:Function is locally const.
Function found to be noreturn: main
Function found to be const: int main()/18
Declaration updated to be const: int main()/18
Function found to be nothrow: main
Introduced new external node (void __builtin_unreachable()/32).
int main ()
{
int * D.3130;
int * p1;
int * _3(D);
<bb 2> [count: 0]:
__builtin_unreachable ();
I think CD-DCE shouldn't remove the call as it's looping and noreturn. It
doesn't mark the allocation as necessary because of -fallocation-dce:
if (callee != NULL_TREE
&& flag_allocation_dce
&& DECL_IS_REPLACEABLE_OPERATOR_NEW_P (callee))
return;
we fail to check gimple_call_from_new_or_delete here I think (we later do
it in most other places). But we maybe should never remove a control
stmt which a noreturn call is, even more so as it can throw (yeah, we
remove "dead" exceptions, but together with noreturn this doesn't quite
match).
Adding gimple_call_from_new_or_delete () will fix the testcase at hand
but I think the same issue would exist with a class scope operator new
triggered by a new expression.
So, it's maybe not wrong we remove the call to ::operator new(), but if
we do we have to preserve the 'return 10;' - we cannot do both, take
advantage of 'noreturn' _and_ elide it.
The behavior for the other testcase is OK I think.
