https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101642
--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:b4fc4df94f703e3b191f503ebe7186500e45d081 commit r12-2575-gb4fc4df94f703e3b191f503ebe7186500e45d081 Author: Jakub Jelinek <ja...@redhat.com> Date: Wed Jul 28 18:41:50 2021 +0200 match.pd: Fix up recent __builtin_bswap16 simplifications [PR101642] The following testcase ICEs. The problem is that for __builtin_bswap16 (and only that, others are fine) the argument of the builtin is promoted to int while the patterns assume it is not and is the same as that of the return type. For the bswap simplifications before these new ones it just means we fail to optimize stuff like __builtin_bswap16 (__builtin_bswap16 (x)) because there are casts in between, but the last one, equality comparison of __builtin_bswap16 with integer constant results in ICE, because we create comparison with incompatible types of the operands, and the other might be fine because usually we bit and the operand before promoting, but I think it is too dangerous to rely on it, one day we find out that because it is operand to such a built in, we can throw away any changes that affect the upper bits and all of sudden it would misbehave. So, this patch introduces converts that shouldn't do anything for bswap{32,64,128} and should fix these issues for bswap16. 2021-07-28 Jakub Jelinek <ja...@redhat.com> PR middle-end/101642 * match.pd (bswap16 (x) == bswap16 (y)): Cast both operands to type of bswap16 for comparison. (bswap16 (x) == cst): Cast bswap16 operand to type of cst. * gcc.c-torture/compile/pr101642.c: New test.
