[Bug debug/66714] New: gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[Bug debug/66714] New: gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

            Bug ID: 66714
           Summary: gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g
                    ICE
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With gomp-4_0-branch, when running target-libgomp testsuite with
--target_board=unix/-O2/-g, we have:

c.exp:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (internal compiler error)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (test for excess errors)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (internal compiler error)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors)
...

c++.exp:
...
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/atomic_capture-1.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (internal compiler error)
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/atomic_capture-1.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (test for excess errors)
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/atomic_capture-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (internal compiler error)
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/atomic_capture-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors)
...

In more detail:
...
src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c:
In function ‘main._omp_fn.44’:
src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c:817:9:
internal compiler error: Segmentation fault
0xebeb50 crash_signal
        src/gcc/toplev.c:380
0x92e939 loc_list_from_tree
        src/gcc/dwarf2out.c:14444
0x92ef5e loc_list_from_tree
        src/gcc/dwarf2out.c:14571
0x92f3e2 loc_list_from_tree
        src/gcc/dwarf2out.c:14645
0x92ef5e loc_list_from_tree
        src/gcc/dwarf2out.c:14571
0x93478c add_location_or_const_value_attribute
        src/gcc/dwarf2out.c:16088
0x940528 gen_variable_die
        src/gcc/dwarf2out.c:19277
0x946189 gen_decl_die
        src/gcc/dwarf2out.c:21028
0x94481d process_scope_var
        src/gcc/dwarf2out.c:20543
0x944896 decls_for_scope
        src/gcc/dwarf2out.c:20568
0x93c0c0 gen_subprogram_die
        src/gcc/dwarf2out.c:18869
0x945e09 gen_decl_die
        src/gcc/dwarf2out.c:20961
0x94708c dwarf2out_decl
        src/gcc/dwarf2out.c:21394
0x9470ae dwarf2out_function_decl
        src/gcc/dwarf2out.c:21402
0x9ecc5b rest_of_handle_final
        src/gcc/final.c:4525
0x9ecfce execute
        src/gcc/final.c:4567
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.
...
>From gcc-bugs-return-491101-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 30 22:23:13 2015
Return-Path: <gcc-bugs-return-491101-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 64953 invoked by alias); 30 Jun 2015 22:23:12 -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 64926 invoked by uid 48); 30 Jun 2015 22:23:08 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE
Date: Tue, 30 Jun 2015 22:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: ice-on-valid-code, openacc
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66714-4-5odn1cmN9S@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66714-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66714-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg03433.txt.bz2
Content-length: 1911

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

--- Comment #1 from vries at gcc dot gnu.org ---
For c.exp, at -Ofast/-g, this failure looks similar:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-1.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (internal compiler error)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-1.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (test for excess errors)
...

In more detail:
...
src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-1.c:
In function ‘test_reductions_minmax._omp_fn.6’:
src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-1.c:96:1:
internal compiler error: Segmentation fault
0xebeb50 crash_signal
        src/gcc/toplev.c:380
0x92e939 loc_list_from_tree
        src/gcc/dwarf2out.c:14444
0x92ef5e loc_list_from_tree
        src/gcc/dwarf2out.c:14571
0x92f3e2 loc_list_from_tree
        src/gcc/dwarf2out.c:14645
0x92ef5e loc_list_from_tree
        src/gcc/dwarf2out.c:14571
0x93478c add_location_or_const_value_attribute
        src/gcc/dwarf2out.c:16088
0x940528 gen_variable_die
        src/gcc/dwarf2out.c:19277
0x946189 gen_decl_die
        src/gcc/dwarf2out.c:21028
0x94481d process_scope_var
        src/gcc/dwarf2out.c:20543
0x944896 decls_for_scope
        src/gcc/dwarf2out.c:20568
0x93c0c0 gen_subprogram_die
        src/gcc/dwarf2out.c:18869
0x945e09 gen_decl_die
        src/gcc/dwarf2out.c:20961
0x94708c dwarf2out_decl
        src/gcc/dwarf2out.c:21394
0x9470ae dwarf2out_function_decl
        src/gcc/dwarf2out.c:21402
0x9ecc5b rest_of_handle_final
        src/gcc/final.c:4525
0x9ecfce execute
        src/gcc/final.c:4567
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.
...
>From gcc-bugs-return-491102-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 30 22:36:52 2015
Return-Path: <gcc-bugs-return-491102-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 95539 invoked by alias); 30 Jun 2015 22:36:52 -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 95496 invoked by uid 48); 30 Jun 2015 22:36:48 -0000
From: "kkojima at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4
Date: Tue, 30 Jun 2015 22:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kkojima at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64833-4-ZqdjN0VaXS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64833-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64833-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-06/txt/msg03434.txt.bz2
Content-length: 868

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

--- Comment #20 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #17)
> Increasing insn lengths unnecessarily might result in some unlucky constant
> pool placements and far branches and some code might get worse.  On the
> other hand, constant pool placement and far branch code generation is "a
> matter of luck" anyway.

The tests for the patch in c#16 has been done successfully on trunk.
On second thought, you are right about "a matter of luck" which is
proved by this corner case bug itself reproduced only with rather
exotic options.  Even the patch doesn't affect existing codes, a tiny
change of options or environment variables will perturb the results.
I'll apply the patch in c#16 on trunk and backport it to 4.9/5 if
the usual tests are OK for those branches.

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 35889
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35889&action=edit
Add testcase, no need to set --target_board=unix/-O2/-g

$ make -k -j5 check-target-libgomp RUNTESTFLAGS=c.exp=pr66714.c

...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (internal compiler error)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (test for excess errors)
UNRESOLVED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 compilation failed to
produce executable
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (internal compiler error)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors)
UNRESOLVED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 compilation failed to produce
executable
...

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
The cause of the SIGSEGV is that for loc fdata.5 in main._omp_fn.46
DECL_HAS_VALUE_EXPR_P (loc) is set, but DECL_VALUE_EXPR (loc) is NULL:
...
Program received signal SIGSEGV, Segmentation fault.
0x000000000092e8c9 in loc_list_from_tree (loc=0x0, want_address=0, context=0x0)
    at /home/vries/gcc_versions/devel/gomp-4_0-branch/src/gcc/dwarf2out.c:14444
14444     switch (TREE_CODE (loc))
(gdb) up
#1  0x000000000092eeef in loc_list_from_tree (loc=0x7ffff5f03870,
want_address=0, context=0x0)
    at /home/vries/gcc_versions/devel/gomp-4_0-branch/src/gcc/dwarf2out.c:14571
14571                                      want_address, context);
(gdb) l
14566   
14567       case PARM_DECL:
14568       case RESULT_DECL:
14569         if (DECL_HAS_VALUE_EXPR_P (loc))
14570           return loc_list_from_tree (DECL_VALUE_EXPR (loc),
14571                                      want_address, context);
14572         /* FALLTHRU */
14573   
14574       case FUNCTION_DECL:
14575         {
(gdb) call debug_generic_expr (loc)
fdata.5
(gdb) call current_function_name ()
$1 = 0x7ffff5efc190 "main._omp_fn.46"
...

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3852 bytes --]

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

--- Comment #4 from vries at gcc dot gnu.org ---
Created attachment 35890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35890&action=edit
patch to detect problem earlier

Using this patch, we can trigger the problem earlier:
...
In file included from
src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c:4:0:
src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c:
In function ‘main._omp_fn.46’:
src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c:853:9:
internal compiler error: in decl_value_expr_lookup, at tree.c:6773
0x11c902b decl_value_expr_lookup(tree_node*)
        src/gcc/tree.c:6773
0xa43cae instantiate_expr
        src/gcc/function.c:1851
0x11d914e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, default_hashset_traits>*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set<tree_node*, default_hashset_traits>*))
        src/gcc/tree.c:11132
0xa43e5f instantiate_decls_1
        src/gcc/function.c:1874
0xa443d2 instantiate_decls
        src/gcc/function.c:1922
0xa44874 instantiate_virtual_regs
        src/gcc/function.c:1979
0xa448da execute
        src/gcc/function.c:2015
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.
...

The problem now also triggers without -g.
>From gcc-bugs-return-491254-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 02 11:29:07 2015
Return-Path: <gcc-bugs-return-491254-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14080 invoked by alias); 2 Jul 2015 11:29:07 -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 14048 invoked by uid 48); 2 Jul 2015 11:29:03 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE
Date: Thu, 02 Jul 2015 11:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: ice-on-valid-code, openacc
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-66714-4-y7dWhViqPK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66714-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66714-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-07/txt/msg00144.txt.bz2
Content-length: 399

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

--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 35891
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5891&actioníit
Patch to make error more verbose

Using this patch, we get a more verbose error:
...
decl_value_expr_lookup could not find mapping for from 0x7fb78598a870 in
function main._omp_fn.46
from: fdata.5
...

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
Created attachment 35892
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35892&action=edit
patch to trace decl_value_expr_insert

Using this patch, we trace decl_value_expr_insert

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 35893
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35893&action=edit
Resulting trace.

The from that cannot be found:
...
decl_value_expr_lookup could not find mapping for from 0x7fb79849d870 in
function main._omp_fn.46
from: fdata.5
...

is indeed inserted at some point (though in a different function):
...
decl_value_expr_insert from 0x7fb79849d870 to 0x7fb798539cf8 in function main
from: fdata.5
to: *.omp_data_i->fdata.5
...

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
Created attachment 35894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35894&action=edit
patch to check overwrite

This patch checks whether hash element is accidentally overwritten by another.
The assert does not trigger.

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Created attachment 35895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35895&action=edit
patch to trace garbage collection

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
Created attachment 35896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35896&action=edit
Updated trace

So the mapping we cannot find:
...
decl_value_expr_lookup could not find mapping for from 0x7fc0fe842870 in
function main._omp_fn.46
from: fdata.5
...

is set here:
...
decl_value_expr_insert from 0x7fc0fe842870 to 0x7fc0fe8decf8 in function main
from: fdata.5
to: *.omp_data_i->fdata.5
...

But then freed here:
...
Garbage collection freeing map entry with from 0x7fc0fe842870 and to
0x7fc0fe8decf8 in function main._omp_fn.25
...

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org ---
The test passes with:

/* { dg-additional-options "--param ggc-min-expand=1000000000 --param
ggc-min-heapsize=1000000000" } */

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #12 from vries at gcc dot gnu.org ---
Created attachment 35908
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35908&action=edit
patch to be more aggressive in gt_cleare_cache

Using this patch, we can trigger the problem with minimal testcase, and also
for openmp:
...
$ cat libgomp/testsuite/libgomp.c/pr66714.c
* { dg-do "compile" } */
/* { dg-additional-options "--param ggc-min-expand=0" } */
/* { dg-additional-options "--param ggc-min-heapsize=0" } */
/* { dg-additional-options "-g" } */

/* Minimized from on target-2.c.  */

void
fn3 (int x)
{
  double b[3 * x];
  int i;
  #pragma omp target
    #pragma omp parallel for
      for (i = 0; i < x; i++)
        b[i] += 1;
}
...

[Bug debug/66714] ICE in loc_list_from_tree with -g

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |6.0
            Summary|gomp4:                      |ICE in loc_list_from_tree
                   |libgomp.oacc-c-c++-common/a |with -g
                   |tomic_capture-1.c -g ICE    |

--- Comment #13 from vries at gcc dot gnu.org ---
(In reply to vries from comment #12)
> Created attachment 35908 [details]
> patch to be more aggressive in gt_cleare_cache
> 
> Using this patch, we can trigger the problem with minimal testcase, and also
> for openmp:

This is a trunk patch, not a gomp-4-0-branch patch.

[Bug debug/66714] ICE in loc_list_from_tree with -g

[vries at gcc dot gnu.org]

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

--- Comment #14 from vries at gcc dot gnu.org ---
1.

In lower_omp_target for function fn3, we handle clause 'map(alloc:bD.1833
[pointer assign, bias: 0])' with variable-sized bD.1833.
The var bD.1833 has value-expr *b.0D.1844. For b.0D.1844, we search the
associated decl with lookup_decl, and find b.0D.1854. We set the value-expr for
b.0D.1854 to '*.omp_data_iD.1851->b.0D.1870'.

Associated code:
...
        if (DECL_SIZE (var)
            && TREE_CODE (DECL_SIZE (var)) != INTEGER_CST)
          {
            tree var2 = DECL_VALUE_EXPR (var);
            gcc_assert (TREE_CODE (var2) == INDIRECT_REF);
            var2 = TREE_OPERAND (var2, 0);
            gcc_assert (DECL_P (var2));
            var = var2;
          }

        if (!maybe_lookup_field (var, ctx))
          continue;

        if (offloaded)
          {
            x = build_receiver_ref (var, true, ctx);
            tree new_var = lookup_decl (var, ctx);
            if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_POINTER
                && !OMP_CLAUSE_MAP_ZERO_BIAS_ARRAY_SECTION (c)
                && TREE_CODE (TREE_TYPE (var)) == ARRAY_TYPE)
              x = build_simple_mem_ref (x);
            SET_DECL_VALUE_EXPR (new_var, x);
            DECL_HAS_VALUE_EXPR_P (new_var) = 1;
          }
...


2.

In replace_block_vars_by_duplicates, called from move_sese_region_to_fn, called
from expand_omp_target: 
- we copy the value-expr *b.0D.1854 from bD.1855 to bD.1916, and
- we copy the value-expr *.omp_data_iD.1851->b.0D.1870 from b.0D.1854 to
  b.0D.1917

Associated code:
...
      t = *tp;
      if (TREE_CODE (t) != VAR_DECL && TREE_CODE (t) != CONST_DECL)
        continue;
      replace_by_duplicate_decl (&t, vars_map, to_context);
      if (t != *tp)
        {
          if (TREE_CODE (*tp) == VAR_DECL && DECL_HAS_VALUE_EXPR_P (*tp))
            {
              SET_DECL_VALUE_EXPR (t, DECL_VALUE_EXPR (*tp));
              DECL_HAS_VALUE_EXPR_P (t) = 1;
            }
          DECL_CHAIN (t) = DECL_CHAIN (*tp);
          *tp = t;
        }
...


3.

In expand_omp_target for function fn3._omp_fn.0 we remove b.0D.1854 and bD.1855
from the local_decls, because the DECL_CONTEXT is fn3, rather than
fn3._omp_fn.0.

Associated code:
...
      /* Remove non-local VAR_DECLs from child_cfun->local_decls list.  */
      num = vec_safe_length (child_cfun->local_decls);
      for (srcidx = 0, dstidx = 0; srcidx < num; srcidx++)
        {
          t = (*child_cfun->local_decls)[srcidx];
          if (DECL_CONTEXT (t) == cfun->decl)
            continue;
          if (srcidx != dstidx)
            (*child_cfun->local_decls)[dstidx] = t;
          dstidx++;
        }
...


4.

Now that b.0D.1854 and bD.1855 are no longer declared in a function, they're no
longer live, and during garbage collection, we remove:
- cache entry (b.0D.1854, *.omp_data_iD.1851->b.0D.1870), and
- cache entry (bD.1855, *b.0D.1854)
from hash table value_expr_for_decl.


5.

During dwarf processing of fn3._omp_fn.0, we process a scope with decl bD.1916,
which has value-expr *b.0D.1854. When processing b.0D.1854 in
loc_list_from_tree, we run into the sigsegv because the value-expr for
b.0D.1854 is NULL (since the entry has been removed from the hash table).

Associated code:
...
      /* FALLTHRU */

    case PARM_DECL:
    case RESULT_DECL:
      if (DECL_HAS_VALUE_EXPR_P (loc))
        return loc_list_from_tree (DECL_VALUE_EXPR (loc),
                                   want_address, context);
...

[Bug debug/66714] ICE in loc_list_from_tree with -g

[vries at gcc dot gnu.org]

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

--- Comment #15 from vries at gcc dot gnu.org ---
My guess at this point is that the problem is that in 
replace_block_vars_by_duplicates, we replace the old decls in the block with
new decls, but that the value-exprs that we copy from the old to the new decls
still contain the old decls.

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

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

--- Comment #16 from vries at gcc dot gnu.org ---
Moving component from debug to libgomp. The assert is with -g, but the code
copying untranslated value-exprs is always active, not just with -g.

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[vries at gcc dot gnu.org]

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

--- Comment #17 from vries at gcc dot gnu.org ---
Created attachment 35918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35918&action=edit
update gzipped trace

latest trace

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[vries at gcc dot gnu.org]

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

--- Comment #18 from vries at gcc dot gnu.org ---
Created attachment 35919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35919&action=edit
combined testcase/trigger/tracing patch

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[vries at gcc dot gnu.org]

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

--- Comment #19 from vries at gcc dot gnu.org ---
This ( https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00711.html ) patch fixes
the ICE (perhaps without fixing the root cause).

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[cesar at gcc dot gnu.org]

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

cesar at gcc dot gnu.org changed:

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

--- Comment #20 from cesar at gcc dot gnu.org ---
Created attachment 36030
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36030&action=edit
replace block vars fix

Tom, thanks for your detailed analysis and reduced test case. As you suspected,
replace_block_vars_by_duplicates isn't updating the DECL_VALUE_EXPR properly.
That function is setting the value expr to be the original decl, not the new
offloaded copy. My patch teaches it how to use an offloaded copy. 

All of the value exprs we're interested in for openacc are INDIRECT_REFs and I
think that holds true for openmp too. Fortran cray pointers caused some minor
problems because those get represented by a INDIRECT_REF to a CONVERT_EXPR as
you in the patch. 

I tested this patch in gomp-4_0-branch libgomp and everything appears to work.
Does this issue present in trunk too?

Cesar

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[vries at gcc dot gnu.org]

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

--- Comment #21 from vries at gcc dot gnu.org ---
(In reply to cesar from comment #20)
> Created attachment 36030 [details]
> replace block vars fix
> 
> Tom, thanks for your detailed analysis and reduced test case. As you
> suspected, replace_block_vars_by_duplicates isn't updating the
> DECL_VALUE_EXPR properly.

Yeah, and AFAIU Michaels analysis (
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01037.html ) he agrees that that
is the problem.

> That function is setting the value expr to be the
> original decl, not the new offloaded copy. My patch teaches it how to use an
> offloaded copy. 
> 

Cool.

> All of the value exprs we're interested in for openacc are INDIRECT_REFs and
> I think that holds true for openmp too. Fortran cray pointers caused some
> minor problems because those get represented by a INDIRECT_REF to a
> CONVERT_EXPR as you in the patch. 
> 

> --- a/gcc/tree-cfg.c	
> +++ a/gcc/tree-cfg.c	
> @@ -6916,7 +6916,29 @@ replace_block_vars_by_duplicates (tree block, hash_map<tree, tree> *vars_map,
>  	{
>  	  if (TREE_CODE (*tp) == VAR_DECL && DECL_HAS_VALUE_EXPR_P (*tp))
>  	    {
> -	      SET_DECL_VALUE_EXPR (t, DECL_VALUE_EXPR (*tp));
> +	      tree x = DECL_VALUE_EXPR (*tp);
> +
> +	      if (TREE_CODE (x) == INDIRECT_REF)
> +		{
> +		  tree expr = TREE_OPERAND (x, 0);
> +		  tree decl;
> +
> +		  if (CONVERT_EXPR_CODE_P (TREE_CODE (expr)))
> +		    decl = TREE_OPERAND (expr, 0);
> +		  else
> +		    decl = expr;
> +
> +		  replace_by_duplicate_decl (&decl, vars_map, to_context);
> +
> +		  if (CONVERT_EXPR_CODE_P (TREE_CODE (expr)))
> +		    expr = build1 (TREE_CODE (expr), TREE_TYPE (expr), decl);
> +		  else
> +		    expr = decl;
> +
> +		  x = build_simple_mem_ref (expr);
> +		}

How about 

+             else
+               gcc_unreachable ();

?

That makes sure you run into all the unhandled cases.


> I tested this patch in gomp-4_0-branch libgomp and everything appears to
> work. Does this issue present in trunk too?

Yep, this PR was originally filed as gomp-4_0-branch PR but, I changed it to
trunk PR at comment 13.
>From gcc-bugs-return-492976-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 21 23:21:57 2015
Return-Path: <gcc-bugs-return-492976-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29032 invoked by alias); 21 Jul 2015 23:21:57 -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 28984 invoked by uid 48); 21 Jul 2015 23:21:53 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/20397] improve diagnostic for 'is inaccessible' error
Date: Tue, 21 Jul 2015 23:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 3.4.2
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-20397-4-l9rePV0mwV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-20397-4@http.gcc.gnu.org/bugzilla/>
References: <bug-20397-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg01866.txt.bz2
Content-length: 1240

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

--- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #18)
> (In reply to Jonathan Wakely from comment #17)
> > FWIW for the original testcase G++ now says:
> > 
> > a.cc:9:8: error: ‘class A A::A’ is inaccessible within this context
> >   int c(A *a) { return 7; }
> >         ^
> 
> Probably we are treating 'A::A' as a type defined in A.  This seems wrong. 

Not really, 'A' is the name of a type, and it is declared in A (as the injected
class name).

> Perhaps enforce_access could use basetype_path to explain why it is
> inaccessible in the same way as Clang does.
> 
> In my ideal world, it would say:
> 
> error: ‘class A’ is inaccessible within this context
>   int c(A *a) { return 7; }
>         ^
> note: constrained by implicitly private inheritance here
> class B : A {
>           ^

I don't like "constrained by implicitly private inheritance", the term
"constrained" is used in other contexts in C++ but not related to access
control.

I think it would be better to say that name lookup found 'A' in the base class
A, where it is inaccessible.
>From gcc-bugs-return-492977-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 21 23:25:07 2015
Return-Path: <gcc-bugs-return-492977-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 34768 invoked by alias); 21 Jul 2015 23:25:07 -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 34727 invoked by uid 48); 21 Jul 2015 23:25:02 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/66963] __builtin_constant_p and __builtin_choose_expr do not agree on what is a constexpr with -O2
Date: Tue, 21 Jul 2015 23:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 5.1.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66963-4-YyNCgiQYEB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66963-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66963-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-07/txt/msg01867.txt.bz2
Content-length: 242

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I thought this is documented somewhere but __builtin_choose_expr only really
accept constant literals and not constexprs.

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[cesar at gcc dot gnu.org]

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

--- Comment #22 from cesar at gcc dot gnu.org ---
(In reply to vries from comment #21)

> How about 
> 
> +             else
> +               gcc_unreachable ();
> 
> ?
> 
> That makes sure you run into all the unhandled cases.

Good idea. Unfortunately, that caused 4696 new unexpected failures. Maybe some
of those value exprs are VAR_DECLs. I'll investigate this tomorrow.

> > I tested this patch in gomp-4_0-branch libgomp and everything appears to
> > work. Does this issue present in trunk too?
> 
> Yep, this PR was originally filed as gomp-4_0-branch PR but, I changed it to
> trunk PR at comment 13.

Thanks. I'll check out trunk.

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[cesar at gcc dot gnu.org]

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

--- Comment #23 from cesar at gcc dot gnu.org ---
Created attachment 36037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36037&action=edit
patch to handle different types of value exprs

This new patch handles other types besides INDIRECT_REFs. I kept on having to
add support for other tree codes before I got everything to work and I suspect
that I may have missed some. The general case is probably going to be messy.
Still, I like your idea of using gcc_unreachable for unrecognized value exprs.

I'll post this patch to gcc-patches tomorrow if testing comes back clean.

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[cesar at gcc dot gnu.org]

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

--- Comment #24 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Fri Jul 24 14:38:43 2015
New Revision: 226160

URL: https://gcc.gnu.org/viewcvs?rev=226160&root=gcc&view=rev
Log:
        PR 66714

        gcc/
        * tree-cfg.c (struct replace_decls_d): New struct.
        (replace_block_vars_by_duplicates_1): New function.
        (replace_block_vars_by_duplicates): Use it to replace the decls
        in the value exprs by duplicates.

        libgomp/
        * testsuite/libgomp.c/pr66714.c: New test.


Added:
    trunk/libgomp/testsuite/libgomp.c/pr66714.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-cfg.c
    trunk/libgomp/ChangeLog

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[cesar at gcc dot gnu.org]

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

cesar at gcc dot gnu.org changed:

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

--- Comment #25 from cesar at gcc dot gnu.org ---
Fixed in trunk and gomp-4_0-branch.