[Bug tree-optimization/67305] New: [6 Regression] gcc.c-torture/compile/20121027-1.c ICE

[Bug tree-optimization/67305] New: [6 Regression] gcc.c-torture/compile/20121027-1.c ICE

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305

            Bug ID: 67305
           Summary: [6 Regression] gcc.c-torture/compile/20121027-1.c ICE
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jiwang at gcc dot gnu.org
                CC: vmakarov at redhat dot com
  Target Milestone: ---
            Target: arm-none-eabi

since r226850, seen on arm-none-eabi only currently.

it can be easily reproduced by the following command. -mfpu and -mfloat are
necessary.

./cc1 -O3 -nostdinc 20121027-1.c  -march=armv8-a -mthumb
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard

cross cc1 is generated from
   ../gcc/configure --target=arm-none-eabi --enable-languages=c,c++


t.c:13:1: internal compiler error: in decompose_normal_address, at 
rtlanal.c:6090
 }
 ^
0xc94a37 decompose_normal_address
        /space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6090
0xc94d25 decompose_address(address_info*, rtx_def**, machine_mode, 
unsigned char, rtx_code)
        /space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6167
0xc94dc3 decompose_mem_address(address_info*, rtx_def*)
        /space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6187
0xb61149 process_address_1
        /space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:2867
0xb61c4e process_address
        /space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:3124
0xb62607 curr_insn_transform
        /space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:3419
0xb65250 lra_constraints(bool)
        /space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:4421

Richard's initial comments

that looks like a latent issue to me in an area of GCC I am not
familiar with.  I suggest to open a bugreport and CC Vladimir.

The r226850 change caused us to eliminate an induction variable
early (I suspect IVOPTs would have done this later anyway, but
I did not verify that):

Replaced redundant PHI node defining bl_2 with c_1
Replaced c_1 + 1 with bl_15 in all uses of c_16 = c_1 + 1;
Removing dead stmt c_16 = c_1 + 1;
Removing dead stmt bl_2 = PHI <0(2), bl_15(3)>

[Bug rtl-optimization/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-08-21
          Component|tree-optimization           |rtl-optimization
   Target Milestone|---                         |6.0
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug rtl-optimization/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305

Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #2 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
address decomposing can do nothing with too complicated address

(plus:SI (plus:SI (and:SI (ashiftrt:SI (plus:SI (mult:SI (lt:SI (reg/v:SI 117 [
bl ])
                            (const_int 0 [0]))
                        (const_int 63 [0x3f]))
                    (reg/v:SI 117 [ bl ]))
                (const_int 3 [0x3]))
            (const_int -8 [0xfffffffffffffff8]))
        (reg/f:SI 102 sfp))
    (const_int 5 [0x5]))

even arm address legitimize hook can do nothing in this case.

I guess an optimization pass should not produce such address.

[Bug rtl-optimization/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305

--- Comment #3 from Jiong Wang <jiwang at gcc dot gnu.org> ---
>From the tree dump .pre, I understand the tree shape is improved as we deleted
one redundant Phi, but we also noticed there is one regression, we are turning

   _6 = bl_20 >> 6

into something like:

    _5 = c_16 / 64;

While for signed division, we need to generate extra check instruction
sequences, although rtl passes should handle this, but seems to me this is
still a regression, Richard, is it because we have lost some range info after
your patch? the division was turned into right shift after vrp pass.

Anyway, we also need to figure out why after this division change, the rtl pass
crash.

[Bug rtl-optimization/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305

--- Comment #4 from Jiong Wang <jiwang at gcc dot gnu.org> ---
And the very complicated address is generated by combine pass, it runs very
happy by doing the following serious of combination:

Trying 22, 23 -> 24
Successfully matched this instruction
Trying 20 -> 24:
Successfully matched this instruction
Trying 19 -> 24:
Successfully matched this instruction
Trying 17 -> 24:
Successfully matched this instruction
Trying 24 -> 25:
Successfully matched this instruction

So, it has combined eight instructions into one...

[Bug rtl-optimization/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Why does recog think the resulting insn 25 is a valid insn?

[Bug target/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|rtl-optimization            |target

--- Comment #6 from Segher Boessenkool <segher at gcc dot gnu.org> ---
The predicate here is "neon_permissive_struct_operand", and indeed
it is _very_ permissive ;-)

This goes through neon_vector_mem_operand(op, 2, false) which immediately
says "ok!" because there is a frame pointer buried somewhere deep in
that huge expression.  It looks like the "return !strict;" should read
"if (strict) return false;".

[Bug target/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE on arm-none-eabi

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #8 from Jim Wilson <wilson at gcc dot gnu.org> ---
Yes, neon_vector_mem_operand is broken.  The first if statement should not be
returning !strict.  I'd add a "strict &&" test to the if statement, and then
return FALSE, to make it look more like the test in the immediately preceding
function, but Segher's suggestion would work also.  Without the quick exit, the
code will do the regular address checks, and the testcase will work fine, the
invalid address will be rejected.