[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

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

--- Comment #1 from kugan at gcc dot gnu.org ---
Also happens for arm-none-linux-gnueabi-g++ with -mfpu=neon -O3

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[kugan at gcc dot gnu.org]

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

--- Comment #2 from kugan at gcc dot gnu.org ---
can_fix_p is returining CODE_FOR_nothing for converting from tomode=V4SImode to
frommode=V4SFmode with branch 4.9. With trunk it is returning
CODE_FOR_fix_truncv4sfv4si2.

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[kugan at gcc dot gnu.org]

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

--- Comment #3 from kugan at gcc dot gnu.org ---
correction:

with 4.9 when it ICE we have:
Breakpoint 1, expand_fix (to=to@entry=0x7ffff65b5480, from=0x7ffff65b2000,
unsignedp=unsignedp@entry=0) at
/home/kugan/work/sources/gcc-fsf/4.9/gcc/optabs.c:5206
5206    {
(gdb) p debug_rtx (from)
(reg:V4SI 155 [ vect_vec_iv_.19 ])
$23 = void
(gdb) p debug_rtx (to)
(reg:V4SI 281)
$24 = void


with trunk when it is working:
Breakpoint 1, expand_fix (to=to@entry=0x7ffff64a7ac8, from=0x7ffff64a7a98,
unsignedp=unsignedp@entry=0) at
/home/kugan/work/sources/gcc-fsf/gcc/gcc/optabs.c:5196
5196    {
(gdb) p debug_rtx (to)
(reg:V4SI 281)
$12 = void
(gdb) p debug_rtx (from)
(reg:V4SF 280 [ vect__11.23 ])
$13 = void

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #4 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> ---
Hi Kugan,

Are you working on fixing this issue on 4.9?  If so, would you please assign
yourself to this bug.

Thanks.

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-17
                 CC|                            |ramana at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Confirmed.

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[kugan at gcc dot gnu.org]

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

--- Comment #6 from kugan at gcc dot gnu.org ---
-fno-tree-forwprop works.

forwprop propagates:
vect__11.22_96 = (vector(4) float) vect_c.21_94;
vect__13.24_98 = (vector(4) signed int) vect__11.22_96;

into:
vect__13.24_98 = (vector(4) signed int) vect_c.21_94;

this seems to be the reason why we have expand_fix with V4SI in to mode and
from mode. trunk code seems significantly different due to match-and-simplify.


Should we disallow this propagation? Any thoughts?

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Have you bisected what fixed this in 5.1?

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[kugan at gcc dot gnu.org]

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

--- Comment #8 from kugan at gcc dot gnu.org ---
Starting bisect now.

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.3

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to kugan from comment #6)
> -fno-tree-forwprop works.
> 
> forwprop propagates:
> vect__11.22_96 = (vector(4) float) vect_c.21_94;
> vect__13.24_98 = (vector(4) signed int) vect__11.22_96;
> 
> into:
> vect__13.24_98 = (vector(4) signed int) vect_c.21_94;
> 
> this seems to be the reason why we have expand_fix with V4SI in to mode and
> from mode. trunk code seems significantly different due to
> match-and-simplify.
> 
> 
> Should we disallow this propagation? Any thoughts?

So this is a sign-conversion only?  Because I can't see how we reach
expand_fix with V4SI -> V4SI...  unless the operation code remains a
FIX_TRUNC_EXPR which would be a bug.

Checking with a cross.

[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
It is.

*** This bug has been marked as a duplicate of bug 66233 ***