[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 Richard Biener changed: What|Removed |Added Target Milestone|6.4 |6.5 --- Comment #12 from Richard Biener --- GCC 6.4 is being released, adjusting target milestone.
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 Jakub Jelinek changed: What|Removed |Added Target Milestone|6.3 |6.4 --- Comment #11 from Jakub Jelinek --- GCC 6.3 is being released, adjusting target milestone.
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Fri Oct 14 19:36:58 2016 New Revision: 241182 URL: https://gcc.gnu.org/viewcvs?rev=241182=gcc=rev Log: PR middle-end/77959 * expr.c (expand_expr_real_1) : For EXPAND_WRITE return a MEM. * gfortran.dg/pr77959.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr77959.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Created attachment 39802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39802=edit gcc7-pr77959.patch Untested fix.
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- expand_assignment is called with REALPART_EXPRas to, where C.3418 is CONST_DECL. Of course one can't store into a CONST_DECL. If I compare this to how we compile: program p interface subroutine s(x) real :: x end end interface call s(1.0) end subroutine s(x) real :: x x = x + 1 end then the difference is that to_rtx = expand_expr (to, NULL_RTX, VOIDmode, EXPAND_WRITE); in that case returns (mem:SF (reg/f:DI 90) [1 C.3418+0 S4 A32]) and not the CONST_DOUBLE. I'll have a look.
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 --- Comment #7 from Uroš Bizjak --- (In reply to Andrew Pinski from comment #6) > Maybe turning on RTL checking will find the problem is located. Indeed, the rtl-checking enabled build says: internal compiler error: RTL check: expected code 'mem', have 'const_double' in get_mem_attrs, at rtl.h:3300 0xa8b327 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) ../../git/gcc/gcc/rtl.c:811 0x8345d8 get_mem_attrs ../../git/gcc/gcc/rtl.h:3300 0x83038b get_mem_attrs ../../git/gcc/gcc/expr.c:6950 0x83038b store_field ../../git/gcc/gcc/expr.c:6778 0x82d2e3 expand_assignment(tree_node*, tree_node*, bool) ../../git/gcc/gcc/expr.c:5167 0x7253bd expand_gimple_stmt_1 ../../git/gcc/gcc/cfgexpand.c:3649 0x7253bd expand_gimple_stmt ../../git/gcc/gcc/cfgexpand.c:3745
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 --- Comment #6 from Andrew Pinski --- (In reply to Uroš Bizjak from comment #4) > Looks like middle-end problem to me: Maybe turning on RTL checking will find the problem is located.
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 Uroš Bizjak changed: What|Removed |Added Target|x86_64-*-* |x86_64-*-*, alphaev68-*-* --- Comment #5 from Uroš Bizjak --- Also fails for alphaev68-linux-gnu: internal compiler error: Segmentation fault 0x120948993 crash_signal /space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:337 0x120d359b0 alpha_legitimate_address_p /space/homedirs/uros/gcc-svn/trunk/gcc/config/alpha/alpha.c:857 0x1209439eb default_addr_space_legitimate_address_p(machine_mode, rtx_def*, bool, unsigned char) /space/homedirs/uros/gcc-svn/trunk/gcc/targhooks.c:1344 0x12087f613 memory_address_addr_space_p(machine_mode, rtx_def*, unsigned char) /space/homedirs/uros/gcc-svn/trunk/gcc/recog.c:1336 0x120500963 adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long) /space/homedirs/uros/gcc-svn/trunk/gcc/emit-rtl.c:2221 0x120552b07 store_field /space/homedirs/uros/gcc-svn/trunk/gcc/expr.c:6938 0x12054de3b expand_assignment(tree_node*, tree_node*, bool) /space/homedirs/uros/gcc-svn/trunk/gcc/expr.c:5167 0x1203f251b expand_gimple_stmt_1 /space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:3649 0x1203f251b expand_gimple_stmt /space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:3745 0x1203f908b expand_gimple_basic_block /space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:5752 0x1203fc2db execute /space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:6363
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 Uroš Bizjak changed: What|Removed |Added Component|target |middle-end --- Comment #4 from Uroš Bizjak --- Looks like middle-end problem to me: Program received signal SIGSEGV, Segmentation fault. 0x00ef2ddb in ix86_decompose_address (addr=0x41, out=out@entry=0x7fffd490) at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:14954 14954 if (TARGET_64BIT && GET_MODE (addr) == DImode) (gdb) p addr $10 = (rtx) 0x41 (gdb) bt #0 0x00ef2ddb in ix86_decompose_address (addr=0x41, out=out@entry=0x7fffd490) at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:14954 #1 0x00ef4ddc in ix86_legitimate_address_p (addr=, strict=) at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:15668 #2 0x00b1f4af in memory_address_addr_space_p (mode=mode@entry=SFmode, addr=addr@entry=0x41, as=) at /home/uros/gcc-svn/trunk/gcc/recog.c:1336 #3 0x00874930 in adjust_address_1 (memref=memref@entry=0x7fffefdec168, mode=mode@entry=SFmode, offset=offset@entry=0, validate=validate@entry=1, adjust_address=adjust_address@entry=1, adjust_object=adjust_object@entry=0, size=4) at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:2221 #4 0x008b3d1c in store_field (target=0x7fffefdec168, bitsize=32, bitpos=0, bitregion_start=, bitregion_end=, mode=SFmode, exp=0x7fffeffd8c48, alias_set=2, nontemporal=false, reverse=false) at /home/uros/gcc-svn/trunk/gcc/expr.c:6938 #5 0x008afd2f in expand_assignment (to=to@entry=0x7fffeffc4a60, from=from@entry=0x7fffeffd8c48, nontemporal=) at /home/uros/gcc-svn/trunk/gcc/expr.c:5167 #6 0x0079c6ee in expand_gimple_stmt_1 (stmt=0x7fffeffc88c0) at /home/uros/gcc-svn/trunk/gcc/cfgexpand.c:3649 (gdb) f 3 #3 0x00874930 in adjust_address_1 (memref=memref@entry=0x7fffefdec168, mode=mode@entry=SFmode, offset=offset@entry=0, validate=validate@entry=1, adjust_address=adjust_address@entry=1, adjust_object=adjust_object@entry=0, size=4) at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:2221 2221 && (!validate || memory_address_addr_space_p (mode, addr, (gdb) list 2216size = defattrs->size; 2217 2218 /* If there are no changes, just return the original memory reference. */ 2219 if (mode == GET_MODE (memref) && !offset 2220 && (size == 0 || (attrs.size_known_p && attrs.size == size)) 2221 && (!validate || memory_address_addr_space_p (mode, addr, attrs.addrspace))) 2223return memref; 2224 2225 /* ??? Prefer to create garbage instead of creating shared rtl. (gdb) p addr $8 = (rtx) 0x41 Corrupted RTX is passed from adjust_address_1.