From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16619 invoked by alias); 9 Jul 2015 01:11:05 -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 16608 invoked by uid 89); 9 Jul 2015 01:11:05 -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.7 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.7 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: <1436403792.24803.112.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: References: <1436365266.24803.65.camel@surprise> <1436367926.24803.71.camel@surprise> <1436369443.24803.75.camel@surprise> <1436377619.24803.97.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.23 X-SW-Source: 2015-q3/txt/msg00048.txt.bz2 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]