On 19/03/15 13:56, Steven Bosscher wrote:
On Thu, Mar 19, 2015 at 2:45 PM, Kyrill Tkachov wrote:
As pointed out by James Greenhalgh offline the correct thing would have been
to do an
emit_move_insn to let the backend expanders do the right thing (especially
in the concerned
testcase gcc.c-tortu
On 19/03/15 13:56, Steven Bosscher wrote:
On Thu, Mar 19, 2015 at 2:45 PM, Kyrill Tkachov wrote:
As pointed out by James Greenhalgh offline the correct thing would have been
to do an
emit_move_insn to let the backend expanders do the right thing (especially
in the concerned
testcase gcc.c-tortu
On Thu, Mar 19, 2015 at 2:45 PM, Kyrill Tkachov wrote:
> As pointed out by James Greenhalgh offline the correct thing would have been
> to do an
> emit_move_insn to let the backend expanders do the right thing (especially
> in the concerned
> testcase gcc.c-torture/execute/pr65427.c that uses 256-b
On Thu, Mar 19, 2015 at 01:45:19PM +, Kyrill Tkachov wrote:
> Bootstrapped and tested on arm, x86, aarch64.
> This ICE doesn't happen with 4.9 and 4.8 so it's only a regression for GCC
> 5.
> The currently ICE'ins testcase passes now, so no new testcase is added.
Not an expert on this, but it
Hi all,
This patches fixes the ICE reported at
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00949.html
The problem is that gcse generates a (set (reg:OI) (const_int 0)) that
doesn't match anything
in the arm backend. That SET was created through processing an insn
generated by the neon_movoi
