Unrecognizable insn regression in aarch64-linux-gnu-gfortran

[Christopher Covington]

When compiling 481.wrf from SPEC2006, the following regression was noticed, present in the 2013.02 and 2013.03 releases.

gcc-4.7.3-linaro13.02/bin/aarch64-linux-gnu-gfortran -c -o lin47BLD2013-02_generic_aarch64/module_advect_em.fppized.o -J lin47BLD2013-02_generic_aarch64 -I. -I./netcdf/include -DSPEC_CPU_LINUX -DpgiFortran -mcpu=generic -O3 -ffast-math lin47BLD2013-02_generic_aarch64/module_advect_em.fppized.f90
lin47BLD2013-02_generic_aarch64/module_advect_em.fppized.f90: In function 'advect_v':
lin47BLD2013-02_generic_aarch64/module_advect_em.fppized.f90:2700:0: error: unrecognizable insn:
(insn 2909 2908 2910 165 (set (reg:V4SI 16777)
        (unspec:V4SI [
                (const_vector:V4SF [
                        (const_double:SF 0.0 [0x0.0p+0])
                        (const_double:SF 0.0 [0x0.0p+0])
                        (const_double:SF 0.0 [0x0.0p+0])
                        (const_double:SF 0.0 [0x0.0p+0])
                    ])
                (reg:V4SF 9594 [ vect_var_.21059 ])
            ] UNSPEC_CMGE)) lin47BLD2013-01_generic_aarch64/module_advect_em.fppized.f90:1601 -1
     (nil))
lin47BLD2013-02_generic_aarch64/module_advect_em.fppized.f90:2700:0: internal compiler error: in extract_insn, at recog.c:2123

Given the same options, 2013.01 and earlier do not throw the error.

[Matthew Gretton-Dann (matthew-gretton-dann)]

Can you add the output of your command line with -save-temps as attachments please? See http://gcc.gnu.org/bugs/ for more details.

[Zhenqiang Chen (zhenqiang-chen)]

I can reproduce it with 2013.03 release.

With 2013.01 release, it loads {0.0, 0.0, 0.0, 0.0} from literal-pool. While 2013.03 tries to use a simd_mov.

So the issue is most likely triggered by the backport.

        Backport arm-aarch64-4.7 r195010:
        [AARCH64-4.7] Backport: Add support for vector and scalar floating-point immediate loads.

Matt,
 Do you think it is OK to attach the source code from SPEC2006 (no licence issue)?

Thanks!
-Zhenqiang

[Christopher Covington (cov-k)]

Thanks for looking at this. It may be a while before I'm authorized to post the inputs or intermediate outputs here, but I've tried to set the gears in motion.

[Zhenqiang Chen (zhenqiang-chen)]

Root cause:
The compiler swaps some comparison without check, which leads to illegal instructions.

The community had fixed the issue. We might have it in 2013.05 release.

[Christopher Covington (cov-k)]

481.wrf builds successfully with these flags with the 2013.05 release.

[Viktor (vchong)]

Closing per above comment.