[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 --- Comment #11 from ktkachov at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #10) > (In reply to ktkachov from comment #8) > > The ICE is in the wide-int bit_and code when trying to process the rtx: > > > > (and:SI > > (const_int 4294963215 [0xf00f]) > > (const_int 4111 [0x100f]) > > ) > > > > In particular it seems to have problems constructing a wide-int for > > (const_int 4294963215 [0xf00f]) > > Yeah, that isn't a valid SImode const_int. It needs to be sign-extended > rather than zero-extended from bit 31. Thanks, I think I've tracked down the source of it in expand. In particular arm_gen_constant during constant splitting from the andsi3 pattern. Some bit twiddling goes wrong. I'll have a closer look
[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 Ramana Radhakrishnan changed: What|Removed |Added Target Milestone|--- |5.0 Known to fail||5.0
[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 --- Comment #10 from rsandifo at gcc dot gnu.org --- (In reply to ktkachov from comment #8) > The ICE is in the wide-int bit_and code when trying to process the rtx: > > (and:SI > (const_int 4294963215 [0xf00f]) > (const_int 4111 [0x100f]) > ) > > In particular it seems to have problems constructing a wide-int for > (const_int 4294963215 [0xf00f]) Yeah, that isn't a valid SImode const_int. It needs to be sign-extended rather than zero-extended from bit 31.
[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 --- Comment #9 from Joel Sherrill --- I don't build with checking enabled. The normal recommended configuration for an RTEMS toolchain is long since we build newlib at the same time and have iconv options. When I do git bisect, I usually drop the newlib and disable-multilib. But here is how it failed for me per the top level config.log: /users/joel/test-gcc/gcc/configure --verbose --disable-werror --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --with-newlib --enable-multilib --enable-newlib-mb --enable-newlib-iconv --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --enable-newlib-iconv --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 --disable-lto --enable-newlib-io-c99-formats --enable-threads --disable-plugin --enable-languages=c,c++ --target=arm-rtems4.11 --prefix=/users/joel/test-gcc/install-head I am happy to try anything you need.
[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #8 from ktkachov at gcc dot gnu.org --- The ICE is in the wide-int bit_and code when trying to process the rtx: (and:SI (const_int 4294963215 [0xf00f]) (const_int 4111 [0x100f]) ) In particular it seems to have problems constructing a wide-int for (const_int 4294963215 [0xf00f]) Richard, does the trace give you any ideas on this?
[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 --- Comment #7 from ktkachov at gcc dot gnu.org --- (In reply to Ramana Radhakrishnan from comment #5) > Confirmed - svn+ssh://gcc.gnu.org/svn/gcc/trunk@219641 > > Passed in a build I had from 13/01/2015. > > This is a regression. now that I reproduced this I can't un-reproduce ;) This goes for me at least as far back as Dec 15. The ICE is a gcc_checking_assert so perhaps your 13/01 toolchain doesn't have checking enabled?
[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to Ramana Radhakrishnan from comment #5) > Confirmed - svn+ssh://gcc.gnu.org/svn/gcc/trunk@219641 > > Passed in a build I had from 13/01/2015. > > This is a regression. Huh, I reproduced it now with a clean toolchain. Seems that some patch in my tree hid this (from the stack trace don't think anything I have fixes this).
[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-15 Ever confirmed|0 |1 --- Comment #5 from Ramana Radhakrishnan --- Confirmed - svn+ssh://gcc.gnu.org/svn/gcc/trunk@219641 Passed in a build I had from 13/01/2015. This is a regression.
