From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53698 invoked by alias); 8 Jul 2015 14:23:46 -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 53651 invoked by uid 89); 8 Jul 2015 14:23:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-HELO: mx1.redhat.com Message-ID: <1436364950.24803.63.camel@surprise> Subject: Filed PR jit/66811: jit jumps aren't compilable as C (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: <1436046085.24803.35.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.26 X-SW-Source: 2015-q3/txt/msg00026.txt.bz2 On Mon, 2015-07-06 at 22:29 +0100, Dibyendu Majumdar wrote: > On 4 July 2015 at 23:09, Dibyendu Majumdar wrote: > > On 4 July 2015 at 22:41, David Malcolm wrote: > >>> 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. > >> > >> > >> Of course, it could well be a bug at my end. > >> > > Dave, > > Attached is a hacked version in C of the dump from the code. I thought > it might be useful to generate code directly using gcc -O3 -S on this > file - from what I can tell the generated code looks different from > what I am getting in libgccjit. > > BTW the dump of types is problematic in many ways: > 1) types are in wrong order > 2) function types are incorrectly output > 3) array types are incorrectly output > 4) in one case as least a pointer was missing. > > It would be useful if the generated dump was correct C so that it can > directly compiled in gcc. Agreed. I've filed this as an RFE for the jit as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66811