https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669
--- Comment #5 from Jiong Wang <jiwang at gcc dot gnu.org> --- Created attachment 34502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34502&action=edit kk.ii attachment is the reduced testcase. ./cc1 -g -O2 -fprofile-use -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -nostdinc++ kk.ii I found there are two issues, the first is in kk.ii.183t.optimized <bb 15>: _10 = _48 == 39; _11 = _48 == 10; _12 = _10 | _11; if (_12 <= 0) goto <bb 16>; else goto <bb 17>; although there is no correctness issue with the "if (_27 <= 0)", but I think for boolean type "<= 0" is exactly "== 0", so the "<" is uncessary. and in this testcase, "_27" happen to be a CCMP candidate, while CCMP code in aarch64 backend is with the assumption that only EQ/NE comparison will happen on it. in the bottom of aarch64_get_condition_code_1, if comp_cond is not NE/EQ, then -1 always returned. So, I think we should treate LE/LEU as EQ? the second is in do_compare_and_jump in dojump.c, we should use GET_MODE (op0) to get the mode passed to do_compare_rtx_and_jump instead of use TYPE_MODE (type) ? any thoughts? after hack above two issues, pass the testcase. (If the tree level never generate <= for boolean, then only need to modify dojump.c) I am doing more tests and understand the issue in a systematic way...
