From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110107 invoked by alias); 13 Sep 2018 08:34:31 -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 110615 invoked by uid 89); 13 Sep 2018 08:29:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=claimed, 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 08:29:53 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id B0325AD33; Thu, 13 Sep 2018 08:29:50 +0000 (UTC) Date: Thu, 13 Sep 2018 08:42: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-1033443096-1536827390=:16707" X-SW-Source: 2018-09/txt/msg00675.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-1033443096-1536827390=:16707 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-length: 1577 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... Richard. ---1609908220-1033443096-1536827390=:16707--