[Bug debug/63342] New: [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698

[Bug debug/63342] New: [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698

[jtaylor.debian at googlemail dot com]

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

            Bug ID: 63342
           Summary: [5 Regression] ICE in loc_list_from_tree, at
                    dwarf2out.c:14698
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jtaylor.debian at googlemail dot com

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

with gcc 5 current svn rev 215503 attached file creates an ICE.
Bisection showed it was caused by rev 214899 the fix to PR60655.

$ gcc-5.0 -v -g -O2 -std=c99   -fopenmp -c image_iqe.i  -fPIC
Using built-in specs.
COLLECT_GCC=/scratch/jtaylor/gcc/local-trunk/bin//gcc
Target: x86_64-unknown-linux-gnu
Configured with: /tmp/jtaylor/gcc.git/configure --disable-werror
--enable-languages=c,c++,fortran --enable-tls
--prefix=/scratch/jtaylor/gcc/local-trunk --with-gmp=/usr --with-mpfr=/usr
--with-mpc=/usr --with-cloog=/usr --with-ppl=/usr --with-isl=/usr
--disable-bootstrap
Thread model: posix
gcc version 5.0.0 20140923 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-ftrack-macro-expansion=2' '-v' '-g' '-O2' '-std=c99'
'-fopenmp' '-c' '-fPIC' '-o'
'/scratch/jtaylor/data/ccache/4/2/b32515ef366d48ae6a990ef3c32265-38727.o.tmp.ga014413.9629'
'-mtune=generic' '-march=x86-64' '-pthread'

/scratch/jtaylor/gcc/local-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1
-fpreprocessed image_iqe.i -quiet -dumpbase image_iqe.i -mtune=generic
-march=x86-64 -auxbase-strip
/scratch/jtaylor/data/ccache/4/2/b32515ef366d48ae6a990ef3c32265-38727.o.tmp.ga014413.9629
-g -O2 -std=c99 -version -ftrack-macro-expansion=2 -fopenmp -fPIC -o
/tmp/ccq5QE77.s
GNU C (GCC) version 5.0.0 20140923 (experimental) (x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 5.0.0 20140923 (experimental) (x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b7b329711fd6ccb5f987647fb148652d
image_iqe.c: In function ‘g2efunc’:
image_iqe.c:90:1: internal compiler error: in loc_list_from_tree, at
dwarf2out.c:14698
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-462337-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 23 13:16:19 2014
Return-Path: <gcc-bugs-return-462337-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3584 invoked by alias); 23 Sep 2014 13:16:18 -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 3485 invoked by uid 48); 23 Sep 2014 13:16:13 -0000
From: "boger at us dot ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/60406] recover.go: test13reflect2 test failure
Date: Tue, 23 Sep 2014 13:16: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: boger at us dot ibm.com
X-Bugzilla-Status: NEW
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-60406-4-vGgnvXE2I3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60406-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60406-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-09/txt/msg02171.txt.bz2
Content-length: 2554

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`406

--- Comment #9 from boger at us dot ibm.com ---
The patch to fix the recover.go problem causes significant regression in gccgo
when built for ppc64 (BE).  There are 32 unexpected failures in the gcc go
testsuite with the patch 32 unexpected failures in the gcc libgo testsuite.
Without this patch on trunk there are 2 failures in the go testsuites and 1
failure in the libgo testsuite.

I did some debugging on one of the regression failures:  bug113.go.  I found
that the problem occurs in the new code in the patch in
go/gofrontend/statements.cc when creating the expression tree to call
__go_set_defering_fn.  The argument that is being passed is generated through a
call to make_func_code_reference:


      Expression* arg         Expression::make_func_code_reference(function, location);
      Expression* call = Runtime::make_call(Runtime::SET_DEFERING_FN,
                                            location, 1, arg);
      Statement* s = Statement::make_statement(call, true);
      s->determine_types();
      gogo->add_statement(s);


On ppc64le, this works as expected but on ppc64(be) the code that is generated
from this is not the address of the function but the address of the .opd entry
that is used to call the function.  As a result the setting of the deferring
function is incorrect and it does not appear as if it can recover because of
the way __go_can_recover uses the deferring function's address to see if it is
in the correct range.

When I debug this using gdb:

Breakpoint 1, __go_set_defering_fn (defering_fn=0x10020150 <main.$thunk0>) at
/home/boger/gccgo.work/140922/src/libgo/runtime/go-defer.c:78
78      {
Missing separate debuginfos, use: debuginfo-install glibc-2.17-55.el7.ppc64
(gdb) info reg $r3
r3             0x10020150       268566864

>From the objdump, I see this address is in the .opd:
0000000010020150 <main.$thunk0>:
    10020150:   00 00 00 00     .long 0x0
    10020154:   10 00 1c 4c     vsro    v0,v0,v3
    10020158:   00 00 00 00     .long 0x0
    1002015c:   10 02 81 c0     .long 0x100281c0

but the code is actually here, which is the address that should be passed to
__go_set_defering_fn:
0000000010001c4c <.main.$thunk0>:
main.$thunk0():
    10001c4c:   7c 08 02 a6     mflr    r0
    10001c50:   f8 01 00 10     std     r0,16(r1)
    10001c54:   fb e1 ff f8     std     r31,-8(r1)
    10001c58:   f8 21 ff 71     stdu    r1,-144(r1)

Note that the actual function code address is in the first 8 bytes of the .opd
entry for the function.

[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 33612
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33612&action=edit
gcc5-pr63342.patch

Untested fix.  When because of r214899 mem_loc_descriptor (correctly) gives up
(previously we were generating wrong debug info), we retry by trying to
generate debug info from the MEM_EXPR of the MEM, but in this case it contains
a TARGET_MEM_REF which we weren't handling at all.

Perhaps we should just return NULL for TARGET_MEM_REF though, because we can't
do anything for SSA_NAMEs anyway, and I doubt there could be a TARGET_MEM_REF
in MEM_EXPR which would not mention SSA_NAMEs.

The ultimate reason for not generating debug info is that the TLSLD model base
address is precomputed into some register (as it is used multiple times in the
function) and ix86_delegitimize_tls_address can't know which hard register
holds the base address, so the delegitimization fails.  In theory we probably
could emit the symbol@DTPOFF into assembly, but as we right now reject all
UNSPECs that weren't successfully delegitimized, we reject it anyway.

[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Oct  1 20:51:34 2014
New Revision: 215782

URL: https://gcc.gnu.org/viewcvs?rev=215782&root=gcc&view=rev
Log:
    PR debug/63342
    * dwarf2out.c (loc_list_from_tree): Handle MEM_REF with non-zero
    offset, TARGET_MEM_REF and SSA_NAME.

    * gcc.dg/pr63342.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr63342.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c
    trunk/gcc/testsuite/ChangeLog

[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Oct  1 20:57:44 2014
New Revision: 215783

URL: https://gcc.gnu.org/viewcvs?rev=215783&root=gcc&view=rev
Log:
    PR debug/63342
    * dwarf2out.c (loc_list_from_tree): Handle TARGET_MEM_REF and
    SSA_NAME.

    * gcc.dg/pr63342.c: New test.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr63342.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/dwarf2out.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Oct  1 21:01:39 2014
New Revision: 215784

URL: https://gcc.gnu.org/viewcvs?rev=215784&root=gcc&view=rev
Log:
    PR debug/63342
    * dwarf2out.c (loc_list_from_tree): Handle TARGET_MEM_REF and
    SSA_NAME.

    * gcc.dg/pr63342.c: New test.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr63342.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/dwarf2out.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now.

[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698

[jtaylor.debian at googlemail dot com]

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

--- Comment #6 from Julian Taylor <jtaylor.debian at googlemail dot com> ---
thanks, head (and branches) work fine now