From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1564 invoked by alias); 4 Oct 2017 13:56:20 -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 1552 invoked by uid 89); 4 Oct 2017 13:56:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=1200, H*Ad:U*jit, dave, Dave X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham 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 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Oct 2017 13:56:18 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E525EC04B92A; Wed, 4 Oct 2017 13:56:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E525EC04B92A Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dmalcolm@redhat.com Received: from ovpn-116-23.phx2.redhat.com (ovpn-116-23.phx2.redhat.com [10.3.116.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3C5766FEEA; Wed, 4 Oct 2017 13:56:16 +0000 (UTC) Message-ID: <1507125375.2654.60.camel@redhat.com> Subject: Re: [committed] Fix crash accessing builtins in sanitizer.def and after (PR jit/82174) From: David Malcolm To: Michael Cree Cc: jit@gcc.gnu.org Date: Sun, 01 Jan 2017 00:00:00 -0000 In-Reply-To: <20170917100539.4d4rn3fdsk6uk4xh@tower> References: <1505419774-35690-1-git-send-email-dmalcolm@redhat.com> <20170917100539.4d4rn3fdsk6uk4xh@tower> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 04 Oct 2017 13:56:17 +0000 (UTC) X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00001.txt.bz2 On Sun, 2017-09-17 at 22:05 +1200, Michael Cree wrote: > On Thu, Sep 14, 2017 at 04:09:34PM -0400, David Malcolm wrote: > > Calls to gcc_jit_context_get_builtin_function that accessed > > builtins > > in sanitizer.def and after (or failed to match any builtin) led to > > a crash accessing a NULL builtin name. > > [snip] > > This patch updates jit-builtins.c to cope with such entries, fixing > > the > > crash. > > Thanks for fixing that. > > I would now like to get access to the architecture specific builtins. > Any possibility of that being implemented into libgccjit? My project > is basically dead in the water without them. I looked at doing that, but it's a little tricky: In the C and C++ frontends, the target-specific builtins are registered by TARGET_INIT_BUILTINS, which is called as: targetm.init_builtins (); early on. On x86 and x86_64 this hook is implemented by ix86_init_builtins, which does a lot of manipulation using gcc's "tree" type. Currently in the jit, the name lookup of a builtin happens as the jit context is being populated, which is much earlier than when jit_langhook_init is called (when e.g. we could call targetm.init_builtins (); ) i.e. it's happening way before trees etc exist How to fix this? Perhaps the jit could keep the string for the builtin, and defer looking it up (and checking it) to after trees exist: defer checking to immediately after the tree init happens. We could then issue early failure and bail out during the "compile" of the jit context for builtins that are still unrecognized. One thing I don't like about this solution (apart from the complexity) is that it delays error-checking, and it's best to do emit error messages as early as possible. Given that the target-specific builtins seem to all be prefixed with double underscores (e.g. "__builtin_ia32_aesdec128"), perhaps we could delay the lookup for builtins that start with double underscores (not all are target- specific though). Or maybe just delay it for everything? Or add a different entrypoint for accessing such builtins? > Secondly, I am trying to work out how to initialise a vector rvalue > with specified values. Something in the vein of > gcc_jit_new_rvalue_from_int() but creating a type with vector > attribute and where each individual element is set to some specified > value and it may not be the same value for each element. I've implemented: extern gcc_jit_rvalue * gcc_jit_context_new_rvalue_from_vector (gcc_jit_context *ctxt, gcc_jit_location *loc, gcc_jit_type *vec_type, size_t num_elements, gcc_jit_rvalue **elements); which is analogous to: { element0, element1, ... elementN-1} in the C frontend. > The gcc C manual says "vectors can be subscripted as if the vector > were an array [...]" so I tried initialising a vector with > gcc_jit_context_new_array_access() but that fails with errors that > the vector is not a pointer or array at the time of JIT compilation. I haven't implemented that yet; do you need it? Thanks Dave