[4.9 Regression] ICE in final_scan_insn, at final.c:2952 (aarch64-linux-gnu)

Created attachment 92
preprocessed source

seen with 4.9 linaro 2014.07, works with -O1

$ g++ -c -O2 -fPIE pfs_host.ii
/home/doko/tmp/mysql-5.6-5.6.19/storage/perfschema/pfs_host.cc: In function 'PFS_host* find_or_create_host(PFS_thread*, const char*, uint)':
/home/doko/tmp/mysql-5.6-5.6.19/storage/perfschema/pfs_host.cc:289:1: error: could not split insn
 }
 ^
(insn:TI 304 300 305 (parallel [
            (set (reg:SI 2 x2 [orig:153 D.16667 ] [153])
                (mem/v:SI (reg/f:DI 1 x1 [orig:113 D.16671 ] [113]) [-1 S4 A32]))
            (set (mem/v:SI (reg/f:DI 1 x1 [orig:113 D.16671 ] [113]) [-1 S4 A32])
                (unspec_volatile:SI [
                        (ior:SI (mem/v:SI (reg/f:DI 1 x1 [orig:113 D.16671 ] [113]) [-1 S4 A32])
                            (const_int 0 [0]))
                        (const_int 5 [0x5])
                    ] UNSPECV_ATOMIC_OP))
            (clobber (reg:CC 66 cc))
            (clobber (reg:SI 3 x3 [330]))
            (clobber (reg:SI 4 x4 [331]))
        ]) /home/doko/tmp/mysql-5.6-5.6.19/include/my_atomic.h:217 2338 {atomic_fetch_orsi}
     (expr_list:REG_UNUSED (reg:CC 66 cc)
        (expr_list:REG_UNUSED (reg:SI 4 x4 [331])
            (expr_list:REG_UNUSED (reg:SI 3 x3 [330])
                (nil)))))
/home/doko/tmp/mysql-5.6-5.6.19/storage/perfschema/pfs_host.cc:289:1: internal compiler error: in final_scan_insn, at final.c:2952
Please submit a full bug report,
with preprocessed source if appropriate.

Created attachment 104
Reduced preprocessed source code from the example above

The mentioned testcase can be reduced to 47 lines of code.
I cannot reduce anymore.

The error is similiar, but is somehow different from yours:

pfs_host.ii:47:1: error: could not split insn
 }
 ^
(insn:TI 71 72 73 (parallel [
            (set (mem/v:SI (reg/f:DI 19 x19 [117]) [-1 S4 A32])
                (unspec_volatile:SI [
                        (ior:SI (mem/v:SI (reg/f:DI 19 x19 [117]) [-1 S4 A32])
                            (const_int 0 [0]))
                        (const_int 5 [0x5])
                    ] UNSPECV_ATOMIC_OP))
            (clobber (reg:CC 66 cc))
            (clobber (reg:SI 1 x1 [143]))
            (clobber (reg:SI 2 x2 [144]))
        ]) pfs_host.ii:32 2326 {atomic_orsi}
     (expr_list:REG_DEAD (reg/f:DI 19 x19 [117])
        (expr_list:REG_UNUSED (reg:CC 66 cc)
            (expr_list:REG_UNUSED (reg:SI 2 x2 [144])
                (expr_list:REG_UNUSED (reg:SI 1 x1 [143])
                    (nil))))))
pfs_host.ii:47:1: internal compiler error: in final_scan_insn, at final.c:2957
0xb2b8c5 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
 /home/ilya/cbuild2/build/snapshots/gcc.git/gcc/rtl-error.c:109
0x9030b1 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
 /home/ilya/cbuild2/build/snapshots/gcc.git/gcc/final.c:2957
0x903352 final(rtx_def*, _IO_FILE*, int)
 /home/ilya/cbuild2/build/snapshots/gcc.git/gcc/final.c:2027
0x903b52 rest_of_handle_final
 /home/ilya/cbuild2/build/snapshots/gcc.git/gcc/final.c:4453
0x903b52 execute
 /home/ilya/cbuild2/build/snapshots/gcc.git/gcc/final.c:4528
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.launchpad.net/gcc-linaro> for instructions.

The compiler fails after function split_insns (generaged from md) fails with the following arguments:

pattern =

(parallel [
        (set (mem/v:SI (reg/f:DI 19 x19 [117]) [-1 S4 A32])
            (unspec_volatile:SI [
                    (ior:SI (mem/v:SI (reg/f:DI 19 x19 [117]) [-1 S4 A32])
                        (const_int 0 [0]))
                    (const_int 5 [0x5])
                ] UNSPECV_ATOMIC_OP))
        (clobber (reg:CC 66 cc))
        (clobber (reg:SI 1 x1 [143]))
        (clobber (reg:SI 2 x2 [144]))
    ])

insn =

(insn:TI 71 72 73 (parallel [
            (set (mem/v:SI (reg/f:DI 19 x19 [117]) [-1 S4 A32])
                (unspec_volatile:SI [
                        (ior:SI (mem/v:SI (reg/f:DI 19 x19 [117]) [-1 S4 A32])
                            (const_int 0 [0]))
                        (const_int 5 [0x5])
                    ] UNSPECV_ATOMIC_OP))
            (clobber (reg:CC 66 cc))
            (clobber (reg:SI 1 x1 [143]))
            (clobber (reg:SI 2 x2 [144]))
        ]) pfs_host.ii:32 2326 {atomic_orsi}
     (expr_list:REG_DEAD (reg/f:DI 19 x19 [117])
        (expr_list:REG_UNUSED (reg:CC 66 cc)
            (expr_list:REG_UNUSED (reg:SI 2 x2 [144])
                (expr_list:REG_UNUSED (reg:SI 1 x1 [143])
                    (nil))))))

(from gdb output of debug_rtx(pat) and debug_rtx(insn))

Created attachment 110
The patch that fixes error (maybe incorrect!)

The error is related with legacy built-in functions for atomic memory access
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins

Such builtins are expanded to atomic_* instructions at expand pass.

It has been found that usually all atomic_* RTL instructions (except atomic_store*) are splitted out after pass split2 (you can check it by compiling sync-1.c from gcc testuite). So there must not be any atomic_* after split2 (except atomic_store*).
But in our case insn atomic_orsi was not splitted out after split2 and stayed in code till to the final pass.

Final pass also tries to split all instrutions, but it fails with assertion, if at least 1 insn can not be splitted.

So the first erroneous behavior appears at least at split2 pass.

It checks the operand of atomic_orsi, using function aarch64_logical_operand return false for 0.

In the attached patch i tried to allow aarch64_logical_operand to work with 0 case.

Is it correct?

Created attachment 155
2nd variant of reduced testcase

Since some commit the previous testcase compiles fine.

It's strange that 24 is the minimal constant for which the error occurs. If you change it to smaller value, the testcase can be compiled fine.

I have created a fix for this bug that has been successfully tested by doko. I am validating the fix and will update the status as appropriate

Patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02209.html
waiting for further review.

Committed in upstream trunk as rev 217076.