[Bug rtl-optimization/59743] New: [4.9 Regression] ICE: Segmentation fault

[Bug rtl-optimization/59743] New: [4.9 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

            Bug ID: 59743
           Summary: [4.9 Regression] ICE: Segmentation fault
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org

reduced test case:

typedef union {
  long all;
  struct {
    int low;
    int high;
  } s;
} udwords;
int a, b, c, d;
void __udivmoddi4() {
  udwords r;
  d = __builtin_clz(0);
  r.s.low = 0;
  for (; d; --d) {
    r.s.high = r.s.high << 1 | r.s.low >> a;
    r.s.low = r.s.low << b >> 1;
    int s = -r.all;
    c = s;
    r.all--;
  }
}

 % g++ -O2 -c test.ii
test.ii: In function ‘void __udivmoddi4()’:
test.ii:20:1: internal compiler error: Segmentation fault
 }
 ^
0xb4f8df crash_signal
        ../../gcc/gcc/toplev.c:337
0xb056c9 reg_used_between_p(rtx_def const*, rtx_def const*, rtx_def const*)
        ../../gcc/gcc/rtlanal.c:753
0x103e6eb combine_reaching_defs
        ../../gcc/gcc/ree.c:734
0x103e6eb find_and_remove_re
        ../../gcc/gcc/ree.c:973
0x103e6eb rest_of_handle_ree
        ../../gcc/gcc/ree.c:1035
0x103e6eb execute
        ../../gcc/gcc/ree.c:1074
Please submit a full bug report,
>From gcc-bugs-return-439839-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jan 09 20:55:42 2014
Return-Path: <gcc-bugs-return-439839-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6133 invoked by alias); 9 Jan 2014 20:41:06 -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 10218 invoked by uid 48); 9 Jan 2014 20:17:06 -0000
From: "rafael.espindola at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
Date: Thu, 09 Jan 2014 20:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rafael.espindola at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59469-4-icBBqLg1CF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59469-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59469-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: 2014-01/txt/msg00981.txt.bz2
Content-length: 596

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY469

--- Comment #26 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> ---
> Yes, is see the weak symbol both in BasicBlock.o and Function.o.
> However it gets optimized away when I link them with "-flto -O3" into
> libLLVMCore.so (see comment 0).

That optimization seems invalid. There is a explicit template instantiation
definition, so it is valid for other dsos to have an undefined reference.

> Honza says it is an error to have the symbol undefined in
> libLLVMAsmParser.so.
> (The undefined symbol comes from LLParser.cpp)

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org
          Component|rtl-optimization            |middle-end
   Target Milestone|---                         |4.9.0

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Started with r206418.

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The ICE is because cand->insn is earlier in the bb than def_insn.  But too
tired to look why.

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law <law at redhat dot com> ---
No worries Jakub.  I'll take it as it's clearly mine.

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law <law at redhat dot com> ---
I see what's going on.

Basically the code exhibits undefined behaviour (r.s.high is not defined before
its first use in the loop).  Thus the first and only reaching def is appearing
after the first use.

Obviously we shouldn't be faulting here.

Markus -- You might want to go back to your original test and ensure it's not
exhibiting undefined behaviour.  The original code may be exhibiting undefined
behaviour.

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law <law at redhat dot com> ---
I think we can just check DF_INSN_LUIDs here to catch this case.  My systems
are busy right now, but I should be able to nail this down as soon as one frees
up.

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Created attachment 31791
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31791&action=edit
original testcase

Here's the unreduced original.

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #5)
> I think we can just check DF_INSN_LUIDs here to catch this case.  My systems
> are busy right now, but I should be able to nail this down as soon as one
> frees up.

But is DF_INSN_LUID always computed?  I mean, for -O2 it probably is, but what
about -O -free ?  For -O I think the live problem isn't on and thus I think
DF_INSN_LUID isn't computed.  The DF documentation is unfortunately
non-existent :(.

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
  /* The logical uid of the insn in the basic block.  This is valid
     after any call to df_analyze but may rot after insns are added,
     deleted or moved. */
  int luid;

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-01-10
     Ever confirmed|0                           |1

--- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
And note that ree does not make the LUID data stale until after analyzing *all*
the potential transformations.  So the limitations of LUIDs shouldn't be a
problem.

Anyway, patch is in testing.

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law <law at redhat dot com> ---
Thanks.  I'm still working through the RTL/source on the full testcase to see
if there are any uninitialized uses.  Regardless the patch I have here works
for both the reduced and original testcase.  I'll be posting it for review
momentarily.

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[law at gcc dot gnu.org]

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

--- Comment #12 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Fri Jan 10 22:13:18 2014
New Revision: 206545

URL: http://gcc.gnu.org/viewcvs?rev=206545&root=gcc&view=rev
Log:
    PR middle-end/59743
    * ree.c (combine_reaching_defs): Ensure the defining statement
    occurs before the extension when optimizing extensions with
    different source and destination hard registers.

    PR middle-end/59743
    * gcc.c-torture/compile/pr59743.c: New test.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr59743.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ree.c
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[law at redhat dot com]

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

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

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

--- Comment #13 from Jeffrey A. Law <law at redhat dot com> ---
Should be fixed on the trunk now.