https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108392
Bug ID: 108392 Summary: Unexpected optimization in presence of '__attribute__((noipa))' Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- Consider: __attribute__((noipa)) int f(int n) { if (n < 0) n = f(-n); return n; } For x86_64-pc-linux-gnu at recent commit de99049f6fe5341024d4d939ac50d063280f90db, for '-O2' I see: --- 1.c.044t.phiopt1 2023-01-13 12:26:20.196625109 +0100 +++ 1.c.045t.tailr1 2023-01-13 12:26:20.196625109 +0100 [...] __attribute__((noipa, noinline, noclone, no_icf)) int f (int n) { int _1; <bb 2> : - gimple_cond <lt_expr, n_4(D), 0, NULL, NULL> + # gimple_phi <n_4, n_8(D)(0), _1(3)> + gimple_cond <lt_expr, n_4, 0, NULL, NULL> goto <bb 3>; [INV] else goto <bb 4>; [INV] <bb 3> : - gimple_assign <negate_expr, _1, n_4(D), NULL, NULL> - gimple_call <f, n_7, _1> + gimple_assign <negate_expr, _1, n_4, NULL, NULL> + goto <bb 2>; [INV] <bb 4> : - # gimple_phi <n_2, n_4(D)(2), n_7(3)> + # gimple_phi <n_2, n_4(2)> gimple_return <n_2> } I was assuming that '__attribute__((noipa))' would inhibit optimizations such as replacing a 'gimple_call' by knowledge of the body of the callee? (This caused confusion in a different test case, where I didn't expect the recursive function call to disappear.)