[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64

matthew at wil dot cx gcc-bugzilla@gcc.gnu.org
Thu Jan 11 20:32:00 GMT 2018


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653

--- Comment #11 from Matthew Wilcox <matthew at wil dot cx> ---
I'm sorry, I still don't get it.

What I think you're saying is that GCC performs this optimisation:

nr = 1UL << compound_order(page);
atomic_sub_return(x, nr);

into:

if (PageHead(page))
  atomic_sub_return(x, 1);
else
  atomic_sub_return(x, 1UL << page[1].order)

That seems like a great optimisation to me, and I'm all for it.  What I don't
understand is where the b_c_p call gets lost.

Also, this bug is pretty fragile.  If I replace the 'nr' in the call to
atomic_sub_return with '1UL << compound_order(page)', the bug goes away.

Anyway, I have no vested interest in ia64 or the code that's currently using
__b_c_p.  I just want it to stop blocking me getting my patch in.  It's a bit
different from 72785 because I can't just resolve it by removing the checking
code.  Just tell me what the macro should look like.


More information about the Gcc-bugs mailing list