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.
