From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60022 invoked by alias); 13 Sep 2018 09:22:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 60012 invoked by uid 89); 13 Sep 2018 09:22:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.2 spammy=uns, H*c:HHHHH X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Sep 2018 09:22:55 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 9129CAD17; Thu, 13 Sep 2018 09:22:53 +0000 (UTC) Date: Thu, 13 Sep 2018 09:25:00 -0000 From: Richard Biener To: Gerald Pfeifer cc: =?ISO-8859-15?Q?Martin_Li=A8ka?= , gcc-patches@gcc.gnu.org, Jeff Law Subject: Re: [PATCH][4/4][v2] RPO-style value-numbering for FRE/PRE In-Reply-To: Message-ID: References: <015759c4-c4d3-07c2-8e02-1be7a8f4119d@suse.cz> <65f272d6-8aff-7aed-b8e0-ccee6a8e7b73@suse.cz> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609908220-1998221737-1536830573=:16707" X-SW-Source: 2018-09/txt/msg00678.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609908220-1998221737-1536830573=:16707 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-length: 3018 On Thu, 13 Sep 2018, Richard Biener wrote: > On Thu, 13 Sep 2018, Richard Biener wrote: > > > On Thu, 13 Sep 2018, Gerald Pfeifer wrote: > > > > > On Mon, 10 Sep 2018, Martin Li¨ka wrote: > > > > Works for me! One needed to add --wrapper gdb81,--args. So now > > > > I see a nice back-trace. > > > > > > Great! This appears to be a tough one, though breaking FreeBSD/i386 > > > with clang, GCC 6 and GCC 9 (two weeks old), Solaris, HP/UX, so looks > > > like something around glibc vs other libcs? > > > > > > > > > On FreeBSD 10.4 I tried malloc debugging setting MALLOC_CONF=zero:true > > > in the environment, to zero initialize all allocations, alas that also > > > did not change anything. > > > > > > Nor did MALLOC_CONF=tcache:false,junk:true. > > > > > > So my guess is it's a memory allocation issue, but perhaps one level > > > higher than the system functions? > > > > > > > > > Not sure how I can help; clearly not my area of expertise. :-( > > > > If it reproduces with clang as a host compiler maybe you can > > use ASAN with it? I'm not sure if GCCs ASAN support is up to speed. > > IIRC the issues all show up with the stage1 compiler... > > > > Martin's now gone and I have to try set up a VM with FreeBSD to > > debug this myself. > > So I can reproduce with a different backtrace using gcc 6.4.0 as > host compiler (and FreeBSD 10.4). I can't seem to bootstrap > using clang (3.4.1) though. > > IIRC Martin claimed newer FreeBSD are OK for non-obvious reasons > (I see the jemalloc versions are different between FreeBSD releases). > > It probably makes sense to build a libc with debuginfo and > configure jemalloc with debugging, I will try that now... I am testing the following. Bootstrap and regtest running on x86_64-unknown-linux-gnu, bootstrap running on i386-freebsd10.4. Richard. 2018-09-13 Richard Biener PR bootstrap/87134 * tree-ssa-sccvn.c (vn_nary_op_insert_into): Fix assert. (vn_nary_op_insert_pieces_predicated): Do not write useless valid_dominated_by_p entry outside of the allocated storage. Index: gcc/tree-ssa-sccvn.c =================================================================== --- gcc/tree-ssa-sccvn.c (revision 264259) +++ gcc/tree-ssa-sccvn.c (working copy) @@ -3036,8 +3036,7 @@ vn_nary_op_insert_into (vn_nary_op_t vno vno->hashcode = vn_nary_op_compute_hash (vno); gcc_assert (! vno->predicated_values || (! vno->u.values->next - && vno->u.values->valid_dominated_by_p[0] != EXIT_BLOCK - && vno->u.values->valid_dominated_by_p[1] == EXIT_BLOCK)); + && vno->u.values->n == 1)); } slot = table->find_slot_with_hash (vno, vno->hashcode, INSERT); @@ -3216,7 +3215,6 @@ vn_nary_op_insert_pieces_predicated (uns vno1->u.values->result = result; vno1->u.values->n = 1; vno1->u.values->valid_dominated_by_p[0] = pred_e->dest->index; - vno1->u.values->valid_dominated_by_p[1] = EXIT_BLOCK; return vn_nary_op_insert_into (vno1, valid_info->nary, true); } ---1609908220-1998221737-1536830573=:16707--