[Bug target/56720] New: ICE when expanding vcond with floating point unordered comparisons

["ktkachov at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56720

             Bug #: 56720
           Summary: ICE when expanding vcond with floating point unordered
                    comparisons
    Classification: Unclassified
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: ktkachov@gcc.gnu.org
        ReportedBy: ktkachov@gcc.gnu.org
            Target: arm-none-eabi


Created attachment 29720
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29720
ICEing testcase

Compiling the attached testcase with:
-O1 -funsafe-math-optimizations -ftree-vectorize -mfpu=neon -mfloat-abi=hard
causes an ICE on arm-none-eabi

vcond.c: In function 'foo':
vcond.c:7:10: internal compiler error: in expand_insn, at optabs.c:8274
     w[i] = MAX (0.0f, w2[i]);
          ^
0x82f9c5 expand_insn(insn_code, unsigned int, expand_operand*)
    $SOURCE/gcc/gcc/optabs.c:8274
0x83430f expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*,
rtx_def*)
    $SOURCE/gcc/gcc/optabs.c:6777
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Looking at the vcond pattern in neon.md, the predicate for the
comparison operator (arm_comparison_operator) uses maybe_get_arm_condition_code
 which is not needed for vcond since we don't care about the ARM condition code
(we can handle all the comparison cases ourselves in the expander).

Changing the predicate to comparison_operator allows the expander to proceed
but it ICEs again because the pattern doesn't handle the floating point
unordered cases! (i.e. UNGT, UNORDERED, UNLE etc).

Adding support for the unordered cases is very similar to the aarch64 port
added here:
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00957.html


The given testcase works for 4.6 and 4.7 but can be easily made to ICE by
changing
#define MAX(a, b) (a > b ? a : b)
to
#define UNORD(a, b) (__builtin_isunordered (a, b) ? a : b)
causing an ICE again because the code doesn't handle the unordered cases
properly.

I've got a patch to fix it for current trunk.