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

[ktkachov at gcc dot gnu.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: ktkac...@gcc.gnu.org

        ReportedBy: ktkac...@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.