[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Tue Apr 18 13:15:46 2017 New Revision: 246965 URL: https://gcc.gnu.org/viewcvs?rev=246965=gcc=rev Log: PR middle-end/79788 PR middle-end/80375 * c-common.c (c_common_type_for_mode): Don't handle widest_*_literal_type_node here. c_common_signed_or_unsigned_type): Likewise. (c_common_nodes_and_builtins): Set widest_*_literal_type_node to *intTI_type_node or *intDI_type_node depending on whether TImode is supported by the target or not. * gcc.dg/pr79788-1.c: New test. * gcc.dg/pr79788-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr79788-1.c trunk/gcc/testsuite/gcc.dg/pr79788-2.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788 --- Comment #7 from Jakub Jelinek --- Created attachment 41166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41166=edit gcc7-pr79788.patch Untested patch that caps the widest literal type at long long on ILP32 targets.
[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788 --- Comment #6 from Jakub Jelinek --- Even gcc 3.2 ICEs on this.
[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
if ((int128_t) p >= -9223372036854775808 - (int128_t) (signed char) g)
That looks just wrong, I thought with -m32 we don't support int128_t, so there
should be no computations in that type, even when we have too large constant.
void bar (void);
void
foo (long long int p, long long int q)
{
if (p >= 1234567891234567891234567891234567812 + q)
bar ();
}
Apparently we emit int128 arithmetics though, it works even with
-fsanitize=undefined, or with -fwrapv, but not -ftrapv.
[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com --- Comment #4 from Alexander Ivchenko --- This is not a CHKP issue as we ICE without it as well: >gcc-7 /export/users/aivchenk/gnu_ws/gcc/gcc/testsuite/gcc.dg/pr38934.c -m32 >-ftrapv /export/users/aivchenk/gnu_ws/gcc/gcc/testsuite/gcc.dg/pr38934.c:14:35: internal compiler error: in expand_expr_real_2, at expr.c:9569 if (p >= -9223372036854775808LL - (signed char) g) ~~~^ 0xa5e6a3 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/gcc/expr.c:9569 0x8fa8c6 expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3677 0x8fab10 expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3737 0x901bf4 expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5744 0x903656 execute gcc-4.8.3 works though. So it's a regression
[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788 --- Comment #3 from Uroš Bizjak --- (In reply to Martin Liška from comment #2) > Btw. can MPX be used for 32-bit binaries? Is it supported by ICC? MPX is supported on 32-bit i686, but not on x32.
[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Btw. can MPX be used for 32-bit binaries? Is it supported by ICC?
