[Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[zsojka at seznam dot cz]

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

            Bug ID: 59477
           Summary: [4.8/4.9 Regression] ICE: in assign_by_spills, at
                    lra-assigns.c:1281 with -O
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz

Created attachment 31422
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31422&action=edit
partially reduced testcase

Compiler output:
$ gcc -O testcase.C         
testcase.C: In function 'void test1(_Bit_iterator)':
testcase.C:90:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1281
 }
 ^
0xb697f3 assign_by_spills
        /mnt/svn/gcc-trunk/gcc/lra-assigns.c:1281
0xb6a57b lra_assign()
        /mnt/svn/gcc-trunk/gcc/lra-assigns.c:1439
0xb65ac2 lra(_IO_FILE*)
        /mnt/svn/gcc-trunk/gcc/lra.c:2361
0xb13656 do_reload
        /mnt/svn/gcc-trunk/gcc/ira.c:5455
0xb13656 rest_of_handle_reload
        /mnt/svn/gcc-trunk/gcc/ira.c:5584
0xb13656 execute
        /mnt/svn/gcc-trunk/gcc/ira.c:5613
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


$ /mnt/svn/gcc-trunk/binary-latest/bin/gcc -v           
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-205881-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-205881-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20131211 (experimental) (GCC) 


Tested revisions:
r205881 - crash
4.8 r204890 - crash
4.7 r204889 - OK

[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org
   Target Milestone|---                         |4.8.3

[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-12-13
                 CC|                            |vries at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from vries at gcc dot gnu.org ---
I could reproduce this.

[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r175063, but I guess that just made the problem no longer latent.
More reduced testcase:

struct A
{
  unsigned *a, b;
  A (unsigned x) : a (), b (x) {}
};

struct B
{
  B (int);
  B (const B &) {}
};

B bar (B, B, A);
int v;

void
foo ()
{
  B c = 0;
  bar (c, c, A (1ULL << v));
}

I don't think this is a RA bug, the problem is I think that combine changes:
 (insn 20 19 21 2 (set (reg:DI 2 cx)
         (const_int 0 [0])) pr59477.C:20 62 {*movdi_internal_rex64}
      (nil))

-(insn 21 20 22 2 (set (reg:SI 37 r8)
-        (subreg:SI (reg:DI 64) 0)) pr59477.C:20 64 {*movsi_internal}
-     (expr_list:REG_DEAD (reg:DI 64)
-        (nil)))
+(insn 21 20 22 2 (parallel [
+            (set (reg:DI 37 r8)
+                (ashift:DI (reg:DI 65)
+                    (subreg:QI (reg:SI 63 [ v ]) 0)))
+            (clobber (reg:CC 17 flags))
+        ]) pr59477.C:20 503 {*ashldi3_1}
+     (expr_list:REG_UNUSED (reg:CC 17 flags)
+        (expr_list:REG_DEAD (reg:SI 63 [ v ])
+            (expr_list:REG_DEAD (reg:DI 65)
+                (nil)))))

and thus moves a complex operation (which in this case will need %ecx register)
to a place where hard regs need to be live across that and thus makes it hard
for RA to do it's job.

Usually combiner will reject such combination on i?86/x86_64 in the fn argument
hard reg setup insns because of cant_combine_insn_p, but here r8 isn't likely
spilled.  Also, typically cx is initialized after r8, because hard register
arguments are initialized from last argument to first.  But in this case there
is one argument passed in rcx/r8 pair and within a single argument we typically
initialize the first half before the second one.

As no arguments are passed in more than two hard registers, supposedly
the rcx/r8 case is the only problematic one for function arguments, so perhaps
ix86_legitimate_combined_insn could if the output is hard register r8 look for
previous insn if it sets rcx and in that case reject the combination.

In general, e.g. for local register asm variables (e.g. as used for various
syscall inline asm wrappers etc.), I wonder if it isn't unsafe to combine
anything across instructions that set likely spilled hard registers, so perhaps
alternative would be to take that into account when creating LOG_LINKS in
create_log_links.  As clearing the whole next_use array upon seeing
  if (HARD_REGISTER_NUM_P (regno)
      && ! TEST_HARD_REG_BIT (fixed_reg_set, regno)
      && targetm.class_likely_spilled_p (REGNO_REG_CLASS (regno)))
early in the
  for (def_vec = DF_INSN_DEFS (insn); *def_vec; def_vec++)
loop might be too expensive, perhaps we'd need to add another array with a tick
count when next_use was set and increment the tick count on the above mentioned
condition, and consider uses with tick count smaller than the current one as
next_use[] == NULL.

Thoughts on this?

[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Usually combiner will reject such combination on i?86/x86_64 in the fn
> argument hard reg setup insns because of cant_combine_insn_p, but here r8
> isn't likely spilled.  Also, typically cx is initialized after r8, because
> hard register arguments are initialized from last argument to first.  But in
> this case there is one argument passed in rcx/r8 pair and within a single
> argument we typically initialize the first half before the second one.

Is rcx likely spilled?  If so, the situation looks similar to the one dealt
with by likely_spilled_retval_p so maybe the machinery could be extended to
argument registers.

[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #4)
> > Usually combiner will reject such combination on i?86/x86_64 in the fn
> > argument hard reg setup insns because of cant_combine_insn_p, but here r8
> > isn't likely spilled.  Also, typically cx is initialized after r8, because
> > hard register arguments are initialized from last argument to first.  But in
> > this case there is one argument passed in rcx/r8 pair and within a single
> > argument we typically initialize the first half before the second one.
> 
> Is rcx likely spilled?  If so, the situation looks similar to the one dealt
> with by likely_spilled_retval_p so maybe the machinery could be extended to
> argument registers.

Yes, rcx is likely spilled, just r8 isn't and there is rcx = 0; r8 = pseudo1;
in that order before combine and combine is changing it to rcx = 0; r8 =
pseudo2 << pseudo3;

[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
A problem with doing this in create_log_links with a simpler tick counter might
be that it would prevent any combination across most of the CALL_INSNs.
Dunno how often that happens in practice though.
So perhaps for calls we'd need to do something smarter, like if we see a
CALL_INSN, look at CALL_INSN_FUNCTION_USAGE and if there are any likely spilled
regs used for arguments or return value, try to find the range of insns between
last copying of return value reg (if likely spilled) into pseudo(s), or
CALL_INSN if not returning value or return value is not likely spilled, and
first insn to set up call argument in likely spilled argument.  We could then
treat the whole range of insns as a range that clears next_use rather than
setting it to insns in that range, and ignore the above mentioned special
handling of likely spilled hard reg setters in that range.

[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 31844
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31844&action=edit
gcc49-pr59477.patch

Untested fix.

[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Wed Jan 22 19:38:47 2014
New Revision: 206938

URL: http://gcc.gnu.org/viewcvs?rev=206938&root=gcc&view=rev
Log:
2014-01-22  Vladimir Makarov  <vmakarov@redhat.com>

    PR rtl-optimization/59477
    * lra-constraints.c (inherit_in_ebb): Process call for living hard
    regs.  Update reloads_num and potential_reload_hard_regs for all
    insns.

2014-01-22  Vladimir Makarov  <vmakarov@redhat.com>

    PR rtl-optimization/59477
    * g++.dg/pr59477.C: New.


Added:
    trunk/gcc/testsuite/g++.dg/pr59477.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/59477] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |law at redhat dot com
         Resolution|---                         |FIXED

--- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
Fixed by Vlad's commit on the trunk.