[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[rmansfield at qnx dot com]

------- Comment #1 from rmansfield at qnx dot com  2010-09-03 01:13 -------
Created an attachment (id=21680)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21680&action=view)
preprocessed source


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511

[Bug target/45511] New: ICE in neon_valid_immediate, at config/arm/arm.c:8294

[rmansfield at qnx dot com]

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnu
Configured with: ../configure --target=arm-unknown-linux-gnu
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnu
--with-headers=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c++ --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.6.0 20100902 (experimental) [trunk revision 163787] (GCC) 

$ ./xgcc -B. ~/ice.i -c -O3 -ftree-vectorize -mfpu=neon -mfloat-abi=softfp -S
/home/ryan/ice.i: In function 'OverrideFloat16Precisions':
/home/ryan/ice.i:37:59: warning: assignment from incompatible pointer type
[enabled by default]
/home/ryan/ice.i:35:49: internal compiler error: in neon_valid_immediate, at
config/arm/arm.c:8294
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instruction


-- 
           Summary: ICE in neon_valid_immediate, at config/arm/arm.c:8294
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[ramana at gcc dot gnu dot org]

------- Comment #2 from ramana at gcc dot gnu dot org  2010-09-03 10:43 -------
I don't see this with an arm-linux-gnu toolchain for r163798.


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[rmansfield at qnx dot com]

------- Comment #3 from rmansfield at qnx dot com  2010-09-03 13:02 -------
I can still reproduce it with r163811.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[rmansfield at qnx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511

Ryan Mansfield <rmansfield at qnx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #8 from Ryan Mansfield <rmansfield at qnx dot com> ---
ARM OABI is no longer a supported target.

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-06-16 23:15:47 UTC ---
On Thu, 16 Jun 2011, rmansfield at qnx dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511
> 
> --- Comment #6 from Ryan Mansfield <rmansfield at qnx dot com> 2011-06-16 23:00:25 UTC ---
> (In reply to comment #5)
> > EABI targets force 64-bit HOST_WIDE_INT, so the vast majority of users of 
> > the ARM port won't hit this assert.  If you really care about old-ABI 
> > targets (and deprecation of arm-linux-gnu and arm-elf is long overdue), 
> > maybe ARM should just force 64-bit HOST_WIDE_INT unconditionally.
> 
> Thanks for replying, JSM. Looking at config.gcc, there still seems to be a
> quite a number of targets that still use the apcs-gnu ABI. Are you suggesting
> all of the non-EABI targets be deprecated, or just the arm-linux-gnu/arm-elf
> configurations? Is there any downside or reason why not to add
> need_64bit_hwint=yes for all arm targets?

The suggested deprecation is of arm-linux-gnu, obsoleted by 
arm-linux-gnueabi, arm-elf, obsoleted by arm-eabi, and probably 
arm-uclinux, obsoleted by arm-uclinuxeabi.

It's been suggested that 64-bit HOST_WIDE_INT compilers are slower on 
32-bit hosts than those with 32-bit HOST_WIDE_INT, but I haven't seen any 
figures, and think in practice it would be better to use 64-bit 
HOST_WIDE_INT unconditionally for *all* hosts and targets and so eliminate 
one source of host-dependency bugs.

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[rmansfield at qnx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511

--- Comment #6 from Ryan Mansfield <rmansfield at qnx dot com> 2011-06-16 23:00:25 UTC ---
(In reply to comment #5)
> EABI targets force 64-bit HOST_WIDE_INT, so the vast majority of users of 
> the ARM port won't hit this assert.  If you really care about old-ABI 
> targets (and deprecation of arm-linux-gnu and arm-elf is long overdue), 
> maybe ARM should just force 64-bit HOST_WIDE_INT unconditionally.

Thanks for replying, JSM. Looking at config.gcc, there still seems to be a
quite a number of targets that still use the apcs-gnu ABI. Are you suggesting
all of the non-EABI targets be deprecated, or just the arm-linux-gnu/arm-elf
configurations? Is there any downside or reason why not to add
need_64bit_hwint=yes for all arm targets?

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-06-16 21:07:00 UTC ---
On Thu, 16 Jun 2011, rmansfield at qnx dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511
> 
> Ryan Mansfield <rmansfield at qnx dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |ramana at gcc dot gnu.org
> 
> --- Comment #4 from Ryan Mansfield <rmansfield at qnx dot com> 2011-06-16 20:17:00 UTC ---
> (In reply to comment #2)
> > I don't see this with an arm-linux-gnu toolchain for r163798.
> 
> Were you using a 64 bit host?
> 
>    8486       if (immtype == 17)
>    8487         {
>    8488           /* FIXME: Broken on 32-bit H_W_I hosts.  */
>    8489           gcc_assert (sizeof (HOST_WIDE_INT) == 8);

EABI targets force 64-bit HOST_WIDE_INT, so the vast majority of users of 
the ARM port won't hit this assert.  If you really care about old-ABI 
targets (and deprecation of arm-linux-gnu and arm-elf is long overdue), 
maybe ARM should just force 64-bit HOST_WIDE_INT unconditionally.

[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294

[rmansfield at qnx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511

Ryan Mansfield <rmansfield at qnx dot com> changed:

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

--- Comment #4 from Ryan Mansfield <rmansfield at qnx dot com> 2011-06-16 20:17:00 UTC ---
(In reply to comment #2)
> I don't see this with an arm-linux-gnu toolchain for r163798.

Were you using a 64 bit host?

   8486       if (immtype == 17)
   8487         {
   8488           /* FIXME: Broken on 32-bit H_W_I hosts.  */
   8489           gcc_assert (sizeof (HOST_WIDE_INT) == 8);
   8490 
   8491           for (i = 0; i < 8; i++)


I can still reproduce this with trunk, and there's a FIXME with a note about
this bug. Can this PR be moved out of WAITING, or is there some other
information I need to provide?