From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86756 invoked by alias); 24 Jun 2019 20:44:43 -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 86737 invoked by uid 89); 24 Jun 2019 20:44:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:gkrwohb, H*f:sk:gkrwohb X-Spam-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients 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; Mon, 24 Jun 2019 20:44:41 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4CCE23082B25; Mon, 24 Jun 2019 20:44:30 +0000 (UTC) Received: from ovpn-116-166.phx2.redhat.com (ovpn-116-166.phx2.redhat.com [10.3.116.166]) by smtp.corp.redhat.com (Postfix) with ESMTP id AEB785C232; Mon, 24 Jun 2019 20:44:29 +0000 (UTC) Message-ID: <1561409068.3885.28.camel@redhat.com> Subject: Re: [PATCH][gcc] libgccjit: check result_type in gcc_jit_context_new_binary_op From: David Malcolm To: Andrea Corallo Cc: "gcc-patches@gcc.gnu.org" , "jit@gcc.gnu.org" , nd Date: Tue, 01 Jan 2019 00:00:00 -0000 In-Reply-To: References: <1560897082.3885.10.camel@redhat.com> <1561391539.3885.22.camel@redhat.com> 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.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Mon, 24 Jun 2019 20:44:35 +0000 (UTC) X-IsSubscribed: yes X-SW-Source: 2019-q2/txt/msg00010.txt.bz2 On Mon, 2019-06-24 at 16:37 +0000, Andrea Corallo wrote: > David Malcolm writes: > > > On Mon, 2019-06-24 at 15:30 +0000, Andrea Corallo wrote: > > > Hi all, > > > second version for this patch. > > > Given the suggestion for the bit-field one I've tried to improve > > > also > > > here the error message. > > > > Thanks. > > > > > I've added a simple testcase as requested, here I'm trying to do > > > *void=int+int. > > > This without checking would normally crash verifying gimple. > > > > Thanks. FWIW, I think the testcase can be simplified slightly, in > > that > > all that's needed is a bogus call to gcc_jit_context_new_binary_op, > > so > > I don't think the testcase needs the calls to: > > gcc_jit_context_new_function, > > gcc_jit_function_new_block, and > > gcc_jit_block_end_with_return, > > it just needs the types and the gcc_jit_context_new_binary_op call. > > Hi Dave, > thanks for your feedback. > I've tried that but the reproducer is then incomplete with no call to > gcc_jit_context_new_binary_op so I would keep it like it is if you > are > ok with that. Sorry, I think I was unclear. What I meant is that I think you can remove the calls I mentioned, but keep the call to gcc_jit_context_new_binary_op, moving it to be a "top- level" call within create_code (discarding the result). That ought to be enough to trigger the error within the gcc_jit_context. Does that make more sense? > > > More complex cases can be cause of crashes having the > > > result type structures etc... > > > > > > Tested with make check-jit > > > OK for trunk? > > > > Looks good as-is, or you may prefer to simplify the testcase. > > > > Thanks for the patch. > > > > BTW, I don't see you listed in the MAINTAINERS file; are you able > > to > > commit patches yourself? > > > > Dave > > Sorry I realize my "OK for trunk?" was quite misleading. > I'm not a maintainer and till now I have now write access so I can't > apply patches myself. I believe ARM has a corporate copyright-assignment in place with the FSF for GCC contributions. I can commit the patch myself; alternatively, do you want to get commit access? Dave