[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Christophe Lyon --- Now fixed for gcc-6.
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 --- Comment #8 from Christophe Lyon --- Author: clyon Date: Tue Jan 26 15:17:00 2016 New Revision: 232832 URL: https://gcc.gnu.org/viewcvs?rev=232832&root=gcc&view=rev Log: 2016-01-26 Christophe Lyon gcc/ PR target/68620 * config/arm/arm.c (neon_valid_immediate): Handle FP16 vectors. * config/arm/arm_neon.h (__ARM_NUM_LANES, __arm_lane, arm_lanq): New helper macros. (vget_lane_f16): Handle big-endian. (vgetq_lane_f16): Likewise. (vset_lane_f16): Likewise. (vsetq_lane_f16): Likewise. * config/arm/iterators.md (VQXMOV): Add V8HF. (VDQ): Add V4HF and V8HF. (V_reg): Handle V4HF and V8HF. (Is_float_mode): Likewise. * config/arm/neon.md (movv4hf, movv8hf, neon_vdup_nv4hf, neon_vdup_nv8hf): New patterns. (vec_set_internal, vec_extract, neon_vld1_dup): Use VD_LANE iterator. (neon_vld1_dup): Use VQ2 iterator. testsuite/ PR target/68620 * gcc.target/arm/pr68620.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr68620.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm_neon.h trunk/gcc/config/arm/iterators.md trunk/gcc/config/arm/neon.md trunk/gcc/testsuite/ChangeLog
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2015-12-03 00:00:00 |2016-01-18 Ever confirmed|0 |1 --- Comment #7 from Christophe Lyon --- Patch posted at https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01031.html
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 --- Comment #6 from Christophe Lyon --- Adding: +(define_expand "movv4hf" + [(set (match_operand:V4HF 0 "nonimmediate_operand" "") + (match_operand:V4HF 1 "general_operand" ""))] + "TARGET_NEON" + " +") + in neon.md makes this testcase pass, but causes regressions in other tests (vcombine, vcreate, vcvt_f16, vget_high, vget_low, vld1, vld1_dup, vld1_lane, vset, vst1_lane, vcvtf32_f16 now ICE)
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 --- Comment #5 from Christophe Lyon --- (In reply to ktkachov from comment #3) > Does that mean we need to define a movv4hf pattern? Isn't *neon_mov providing this (with the VDX iterator) I think what's not matching here is (set (subreg:SI (reg:V4HF) XXX) (subreg:SI (reg:V4HF) XXX)) because we cannot generate (subreg:SI (reg:V4HF) XXX)
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 --- Comment #4 from Christophe Lyon --- Maybe, that's what I'm trying to figure out. Given the comment in arm.h before the definition of CANNOT_CHANGE_MODE_CLASS, maybe we need to define more patterns, for all the sizes where CANNOT_CHANGE_MODE_CLASS is true on big-endian?
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- Does that mean we need to define a movv4hf pattern?
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2015-12-3
CC||chrbr at gcc dot gnu.org
--- Comment #2 from chrbr at gcc dot gnu.org ---
confirmed. the following ICE with default configure options
arm-none-eabi-gcc -mfp16-format=ieee -mbig-endian -mfpu=neon-fp16
-mfloat-abi=hard ~/neon-fp16-fail.c
#include "arm_neon.h"
float16x4_t
foo (float32x4_t arg)
{
return vcvt_f16_f32 (arg);
}
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 --- Comment #1 from Christophe Lyon --- The problem happens when trying to extract subregs from V4HF. On big-endian, CANNOT_CHANGE_MODE_CLASS returns 1, which at some point makes xpart = operand_subword (x, i, 1, mode); (in emit_move_multi_word) return NULL in xpart, later trigging the assert.
