[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