https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84711
--- Comment #20 from Tamar Christina <tnfchris at gcc dot gnu.org> --- Author: tnfchris Date: Fri Nov 23 12:20:20 2018 New Revision: 266405 URL: https://gcc.gnu.org/viewcvs?rev=266405&root=gcc&view=rev Log: Arm: Fix subreg crash when FP16 and big-endian The original issue comes from the fact that the code does ... foo (... bar) { return bar; } The expansion of the return statement causes GCC to try to return the value in a register. GCC will try to emit the move then, from MEM to REG (due to the SSA temporary.). It checks for a mov optab for this which isn't available and then tries to do the move in bits using emit_move_multi_word. emit_move_multi_word will split the move into sub parts, but then needs to get the sub parts and does this using subregs, but it's told it can't do subregs! The compiler is now stuck in an infinite loop. The way this is worked around in the back-end is that we have move patterns in neon.md that usually just force the register instead of checking with the back-end. This prevents emit_move_multi_word from being needed. However the pattern for V4HF and V8HF were guarded by TARGET_NEON && TARGET_FP16. I don't believe the TARGET_FP16 guard to be needed, because the pattern doesn't actually generate code and requires another pattern for that, and a reg to reg move should always be possible anyway. So allowing the force to register here is safe and it allows the compiler to generate a correct error instead of ICEing in an infinite loop. Regtested on armeb-none-eabi and no regressions. Bootstrapped on arm-none-linux-gnueabihf and no issues. Thanks, Tamar gcc/ 2018-11-23 Tamar Christina <tamar.christ...@arm.com> Backported from mainline. 2018-08-16 Tamar Christina <tamar.christ...@arm.com> PR target/84711 * config/arm/neon.md (movv4hf, movv8hf): Refactored to.. (mov<mov>): ..this and enable unconditionally. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/arm/neon.md
