From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87503 invoked by alias); 4 Jul 2015 21:49:15 -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 87493 invoked by uid 89); 4 Jul 2015 21:49:15 -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: <1436046085.24803.35.camel@surprise> Subject: Re: A possible 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: 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/msg00016.txt.bz2 On Sat, 2015-07-04 at 16:58 +0100, Dibyendu Majumdar wrote: > On 4 July 2015 at 14:20, Dibyendu Majumdar wrote: > > On 4 July 2015 at 13:11, Dibyendu Majumdar wrote: > >> Looks like in the failure case the code is being incorrectly > >> optimized. I wonder if this is a manifestation of the get_address bug, > >> perhaps the real fix will be better than the patch I am using. I will > >> use the latest gcc 5 branch and see if that helps. > >> > > > > Hi Dave, > > > > I am now using the latest gcc-5-branch from gcc github mirror. > > Unfortunately the issue still persists. > > > > If set optimization level to 0 or 1, then it works ok, but at levels 2 > > or 3 the break occurs. > > > > Adding the -fno-strict-aliasing appears to resolve the issue with -O2 > and -O3 but with this enabled the benchmarks are degraded. If "-fno-strict-aliasing" resolved this, then that suggests that there are various casts in the code that if this were C would take us into "undefined behavior" territory, and the optimizer is trying a little too hard. This isn't C, but similar rules apply. If that's what this is, then this is at least a documentation issue with libgccjit; we need to document what the rules are. If this is the case it's normally possible to work around it in C by rewriting casts using unions. Of course, it could well be a bug at my end. In any case, I'm not going to be able to have a proper look at this until Monday (it's the July 4th holiday weekend here in the US); sorry. Sorry about this Dave