[Bug c++/65409] New: ICE in store_field

[Bug c++/65409] New: ICE in store_field

[bugs at qult dot net]

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

            Bug ID: 65409
           Summary: ICE in store_field
           Product: gcc
           Version: 4.9.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugs at qult dot net

Created attachment 35022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35022&action=edit
ICE-triggering source.

I get an ICE with the attached source, from version 4.8 on to the head of the
Git repository.

Output of Git's cc1plus:

 Foo::Foo() Foo::Foo() Foo::Foo() Bar<T>::Bar(U) Bar<T>::Bar(U) [with U = Foo;
T = Foo] Bar<T>::Bar(U) [with U = Foo; T = Foo] Bar<T>::Bar(U) [with U = Foo; T
= Foo] void __static_initialization_and_destruction_0(int, int) void
_GLOBAL__sub_I_a()
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> <visibility> <build_ssa_passes> <chkp_passes>
<opt_local_passes> <free-inline-summary> <whole-program> <inline>Assembling
functions:
 Foo::Foo() Bar<T>::Bar(U) [with U = Foo; T = Foo]
<stdin>: In constructor ‘Bar<T>::Bar(U) [with U = Foo; T = Foo]’:
<stdin>:14:27: internal compiler error: in store_field, at expr.c:6660
0x9cf46f store_field
    ../../gcc/expr.c:6659
0x9d4d10 expand_assignment(tree_node*, tree_node*, bool)
    ../../gcc/expr.c:5000
0x8d5dee expand_call_stmt
    ../../gcc/cfgexpand.c:2388
0x8d5dee expand_gimple_stmt_1
    ../../gcc/cfgexpand.c:3334
0x8d5dee expand_gimple_stmt
    ../../gcc/cfgexpand.c:3488
0x8dc118 expand_gimple_basic_block
    ../../gcc/cfgexpand.c:5500
0x8dd9f7 execute
    ../../gcc/cfgexpand.c:6118

When uncommenting the commented-out fourth attribute of Foo, the ICE goes away.
>From gcc-bugs-return-480225-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 12 18:33:01 2015
Return-Path: <gcc-bugs-return-480225-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 34463 invoked by alias); 12 Mar 2015 18:33:01 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 34392 invoked by uid 48); 12 Mar 2015 18:32:56 -0000
From: "boger at us dot ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/64999] s390x libgo test failure in TestMemoryProfiler
Date: Thu, 12 Mar 2015 18:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: boger at us dot ibm.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64999-4-9Wh2wawEOA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64999-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64999-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg01369.txt.bz2
Content-length: 814

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd999

--- Comment #53 from boger at us dot ibm.com ---
I was taking the approach of only fixing what was known to be broken, and I was
not aware that this was broken on other platforms.  Minimizing risk.  I can
change it for all platforms but these tests are not broken on x86 today with
the pc decremented in both libbacktrace and in pprof.go and I don't understand
why not so I didn't want to mess with it.

I'm not sure if I understand how it would work to add an argument to callback.
The call to callback happens much later after the ip_before_insn flag has been
set:  from inside unwind -> backtrace_pcinfo -> dwarf_fileline ->
dwarf_lookup_pc -> callback.  Do you mean pass this flag as an argument to each
of these functions so it can be passed to callback?

[Bug c++/65409] ICE in store_field

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-12
                 CC|                            |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |4.8.5
     Ever confirmed|0                           |1

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
The backtrace looks the same as in PR64744, but this ICE is reproducible even
on x86_64.

[Bug c++/65409] [4.8/4.9/5 Regression] ICE in store_field

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
            Summary|ICE in store_field          |[4.8/4.9/5 Regression] ICE
                   |                            |in store_field

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r191302.

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
           Priority|P3                          |P2
                 CC|                            |ebotcazou at gcc dot gnu.org
          Component|c++                         |middle-end

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|ebotcazou at gcc dot gnu.org       |
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Fixing.

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've so far came up with:
--- gcc/expr.c.jj    2015-01-19 09:31:15.000000000 +0100
+++ gcc/expr.c    2015-03-13 11:30:25.699805379 +0100
@@ -6656,14 +6656,18 @@ store_field (rtx target, HOST_WIDE_INT b
           && (bitpos % BITS_PER_UNIT) == 0
           && (bitsize % BITS_PER_UNIT) == 0)))
     {
-      gcc_assert (MEM_P (target) && MEM_P (temp)
+      gcc_assert (MEM_P (target)
+              && (MEM_P (temp) || GET_CODE (temp) == PARALLEL)
               && (bitpos % BITS_PER_UNIT) == 0);

       target = adjust_address (target, VOIDmode, bitpos / BITS_PER_UNIT);
-      emit_block_move (target, temp,
-               GEN_INT ((bitsize + BITS_PER_UNIT - 1)
-                    / BITS_PER_UNIT),
-               BLOCK_OP_NORMAL);
+      HOST_WIDE_INT bytesize
+        = (bitsize + BITS_PER_UNIT - 1) / BITS_PER_UNIT;
+      if (GET_CODE (temp) == PARALLEL)
+        emit_group_store (target, temp, TREE_TYPE (exp), bytesize);
+      else
+        emit_block_move (target, temp, GEN_INT (bytesize),
+                 BLOCK_OP_NORMAL);

       return const0_rtx;
     }
which seems to DTRT in this case.

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This looks redundant to me, the following is sufficient:

Index: expr.c
===================================================================
--- expr.c      (revision 221407)
+++ expr.c      (working copy)
@@ -6645,11 +6645,12 @@ store_field (rtx target, HOST_WIDE_INT b
          && mode != TYPE_MODE (TREE_TYPE (exp)))
        temp = convert_modes (mode, TYPE_MODE (TREE_TYPE (exp)), temp, 1);

-      /* If the modes of TEMP and TARGET are both BLKmode, both
-        must be in memory and BITPOS must be aligned on a byte
-        boundary.  If so, we simply do a block copy.  Likewise
-        for a BLKmode-like TARGET.  */
-      if (GET_MODE (temp) == BLKmode
+      /* If TEMP is not a PARALLEL (see below) and its mode and that of TARGET
+        are both BLKmode, both must be in memory and BITPOS must be aligned
+        on a byte boundary.  If so, we simply do a block copy.  Likewise for
+        a BLKmode-like TARGET.  */
+      if (GET_CODE (temp) != PARALLEL
+         && GET_MODE (temp) == BLKmode
          && (GET_MODE (target) == BLKmode
              || (MEM_P (target)
                  && GET_MODE_CLASS (GET_MODE (target)) == MODE_INT

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Doesn't it generate worse code though?  I mean, for BLKmode PARALLEL, forcing
it into some very wide pseudo (TImode in this case, perhaps OImode for even
larger ones?) and then storing might be more expensive than what my patch does.

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, the pessimization (your patch vs. my patch) is only at -O0:
+    movl    %edx, %ecx
+    movl    %ecx, %esi
+    movq    %rdx, %rdi
+    movabsq    $-4294967296, %rcx
+    andq    %rdi, %rcx
+    orq    %rsi, %rcx
+    movq    %rcx, %rdx
is added, for -O1+ the optimizers manage to fix it up.

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The difference is that we go through a pseudo with my version, but the code is
optimal at -O1:

    call    _Z8copy_foo3Foo
    movq    %rax, a(%rip)
    movb    %dl, a+8(%rip)

and the change looks safe enough for all the branches.

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I agree for 4.8/4.9 that your version is safer.
Anyway, you're the RTL maintainer, so I'll let you decide.

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I agree for 4.8/4.9 that your version is safer.
> Anyway, you're the RTL maintainer, so I'll let you decide.

OK, testing went fine, so I'll go for this version on all branches.

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Mon Mar 16 10:26:28 2015
New Revision: 221453

URL: https://gcc.gnu.org/viewcvs?rev=221453&root=gcc&view=rev
Log:
    PR middle-end/65409
    * expr.c (store_field): Do not do a direct block copy if the source is
    a PARALLEL with BLKmode.

Added:
    trunk/gcc/testsuite/g++.dg/pr65049.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expr.c
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Mon Mar 16 10:28:39 2015
New Revision: 221454

URL: https://gcc.gnu.org/viewcvs?rev=221454&root=gcc&view=rev
Log:
    PR middle-end/65409
    * expr.c (store_field): Do not do a direct block copy if the source is
    a PARALLEL with BLKmode.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr65049.C
      - copied unchanged from r221453, trunk/gcc/testsuite/g++.dg/pr65049.C
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/expr.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Mon Mar 16 10:30:29 2015
New Revision: 221456

URL: https://gcc.gnu.org/viewcvs?rev=221456&root=gcc&view=rev
Log:
    PR middle-end/65409
    * expr.c (store_field): Do not do a direct block copy if the source is
    a PARALLEL with BLKmode.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/g++.dg/pr65049.C
      - copied unchanged from r221454, trunk/gcc/testsuite/g++.dg/pr65049.C
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/expr.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Thanks for reporting the problem.