From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35896 invoked by alias); 9 Jul 2015 19:24:25 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 35885 invoked by uid 89); 9 Jul 2015 19:24:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Message-ID: <1436469387.24803.150.camel@surprise> Subject: Re: Filed PR jit/66812 for the code generation issue From: David Malcolm To: Dibyendu Majumdar Cc: jit@gcc.gnu.org Date: Thu, 01 Jan 2015 00:00:00 -0000 In-Reply-To: <1436403792.24803.112.camel@surprise> References: <1436365266.24803.65.camel@surprise> <1436367926.24803.71.camel@surprise> <1436369443.24803.75.camel@surprise> <1436377619.24803.97.camel@surprise> <1436403792.24803.112.camel@surprise> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-SW-Source: 2015-q3/txt/msg00054.txt.bz2 On Wed, 2015-07-08 at 21:03 -0400, David Malcolm wrote: > On Wed, 2015-07-08 at 22:54 +0100, Dibyendu Majumdar wrote: > > Apologies I think the previous description of the flow was incorrect. > > Here is my second attempt (this is doing my head in so I will stop > > now): > > [snip detailed analysis of bytecode] > > Thanks. > > So it's basically: > > * do a bunch of stuff > * then set R(1) to boolean false in that last LOADBOOL op > * then return > > > > 12 [3] LOADBOOL 1 0 0 > > > > (&L->ci->u.l.base[(int)1])->value_.b = (int)0; > > (&L->ci->u.l.base[(int)1])->tt_ = (int)1; > > > > Above sets the register 1 to false and this is the return value. > > I've been poring over the dumps: > https://dmalcolm.fedorapeople.org/gcc/2015-07-08/libgccjit-bug_rdump/ > and I believe the problem is in pass "fre1"; it's eliminating this > statement for some reason: > (&L->ci->u.l.base[(int)1])->value_.b = (int)0; > > so > R1.tt_ = 1 (correct) > but: > R1.value_.i = K0.value_.i (incorrect, is int 10, not 0) > > The statement is still present at pass 034t.ealias: > https://dmalcolm.fedorapeople.org/gcc/2015-07-08/libgccjit-bug_rdump/fake.c.034t.ealias > > but is optimized away in pass 035t.fre1: > https://dmalcolm.fedorapeople.org/gcc/2015-07-08/libgccjit-bug_rdump/fake.c.035t.fre1 > > I'll have a more detailed look tomorrow at why fre1 is getting it wrong. > > [snip] I've managed to create a minimal reproducer for this; see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66812 where libgccjit miscompiles it, but the C frontend (cc1) handles the equivalent C code just fine (even at -O3, without needing -fno-strict-aliasing). So the next step seems to be to step through the fre1 pass in both libgccjit and in cc1, and to see what's different. Yay, progress! Dave