From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58454 invoked by alias); 8 Mar 2017 11:00:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 58294 invoked by uid 89); 8 Mar 2017 11:00:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-23.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-ot0-f195.google.com Received: from mail-ot0-f195.google.com (HELO mail-ot0-f195.google.com) (74.125.82.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Mar 2017 11:00:37 +0000 Received: by mail-ot0-f195.google.com with SMTP id 19so3434146oti.0 for ; Wed, 08 Mar 2017 03:00:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Db8t/nne3fepkhpacadW08X2aagd8d6ys4ujGz8ktjo=; b=ant17EzTb3d6QuX+DnF1hKpITCnr6auj9Q5dP77h/VJ+IShRnZXDk3HTlO4YvdqZxA rvDPBgPSVkP1M9eZY5zstwjBfmxH5tTBi4qB/x1phyot3LDC6VGng5mZyv4BtuRtn0+2 ilSLv9D7xvlXR1AOdGKCaqONwjXeYofIKGqA2yJyQ67OsvOkW3ruBdmwkMpJP+wqJRnC 8Mxf6qrnOxpP50IGu25XgZt/Ob5j4ok0sGuX339yLNNzzOG5isNWl5gOKOBNwPbLIWQ2 s8So/4xoaP66nr4aPWPi8ePlewfLJdf3GdnQvCdkI2Gv2loSgB0jhrngeXvxh0wQPWyI IGQQ== X-Gm-Message-State: AFeK/H2BbI4Etisnnup/ECQqRw3a1niwEa4Tw6TTpE5ObzbliMBEWzg6+dWI3JFajh1kcFrmgqSF6Rdt/aLWvg== X-Received: by 10.157.51.50 with SMTP id f47mr3448641otc.192.1488970832612; Wed, 08 Mar 2017 03:00:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.25 with HTTP; Wed, 8 Mar 2017 03:00:32 -0800 (PST) In-Reply-To: <8f282da1-20ef-ccec-6efe-ca2dff7bca9c@suse.cz> References: <8f282da1-20ef-ccec-6efe-ca2dff7bca9c@suse.cz> From: Richard Biener Date: Wed, 08 Mar 2017 11:00:00 -0000 Message-ID: Subject: Re: [PATCH 1/5] Fix *_CST ICEs connected to MPX. To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Rainer Orth , GCC Patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00361.txt.bz2 On Tue, Mar 7, 2017 at 5:01 PM, Martin Li=C5=A1ka wrote: > On 03/07/2017 03:53 PM, Richard Biener wrote: >> On Tue, Mar 7, 2017 at 3:48 PM, Martin Li=C5=A1ka wrote: >>> On 03/07/2017 11:17 AM, Rainer Orth wrote: >>>> marxin writes: >>>> >>>>> diff --git a/gcc/testsuite/g++.dg/pr79769.C b/gcc/testsuite/g++.dg/pr= 79769.C >>>>> new file mode 100644 >>>>> index 00000000000..f9223db1b2d >>>>> --- /dev/null >>>>> +++ b/gcc/testsuite/g++.dg/pr79769.C >>>>> @@ -0,0 +1,4 @@ >>>>> +/* { dg-do compile { target { ! x32 } } } */ >>>>> +/* { dg-options "-fcheck-pointer-bounds -mmpx -mabi=3Dms" } */ >>>> >>>> ... and again: make this x86-only. >>>> >>>> Rainer >>>> >>> >>> Thanks. I'm sending v2 of the patch. >> >> Hmm, not sure why we should handle REAL_CST here explicitely for example. >> >> Why not, instead of internal_error in the default: case do >> >> bounds =3D chkp_get_invalid_op_bounds (); > > Because chkp_get_invalid_op_bounds() returns bounds that are always valid= and as it's > security extension, I would be strict here in order to not handle somethi= ng that can bypass > the checking. > >> >> there? For the testcase why do we invoke chkp_find_bounds_1 on sth that= is >> a REAL_CST for example? > > It's called when setting bounds in a call expr: > > #0 chkp_find_bounds_1 (ptr=3D0x7ffff6a03720, ptr_src=3D0x7ffff6a03720, i= ter=3D0x7fffffffd5d0) at ../../gcc/tree-chkp.c:3734 > #1 0x0000000000ec7c7d in chkp_find_bounds (ptr=3D0x7ffff6a03720, iter=3D= 0x7fffffffd5d0) at ../../gcc/tree-chkp.c:3768 > #2 0x0000000000ec22e1 in chkp_add_bounds_to_call_stmt (gsi=3D0x7fffffffd= 5d0) at ../../gcc/tree-chkp.c:1901 > #3 0x0000000000ec9a1a in chkp_instrument_function () at ../../gcc/tree-c= hkp.c:4344 > #4 0x0000000000eca4cb in chkp_execute () at ../../gcc/tree-chkp.c:4528 So this happens for calls with mismatched arguments? I believe that if (BOUNDED_TYPE_P (type) || pass_by_reference (NULL, TYPE_MODE (type), type, true)) new_args.safe_push (chkp_find_bounds (call_arg, gsi)); may be misguided given pass_by_reference is not exposed at GIMPLE and thus for the pass_by_reference case it should fall back to "chkp_get_invalid_op_bounds" and thus eventually pass this down as a flag to chkp_find_bounds (or check on call_arg again). Note that here 'type' and call_arg may not match (asking for trouble). Plus 'fntype' is computed bogously (should use gimple_call_fntype). It later does sth like /* For direct calls fndecl is replaced with instrumented version. */ if (fndecl) { tree new_decl =3D chkp_maybe_create_clone (fndecl)->decl; gimple_call_set_fndecl (new_call, new_decl); /* In case of a type cast we should modify used function type instead of using type of new fndecl. */ if (gimple_call_fntype (call) !=3D TREE_TYPE (fndecl)) { tree type =3D gimple_call_fntype (call); type =3D chkp_copy_function_type_adding_bounds (type); gimple_call_set_fntype (new_call, type); } else gimple_call_set_fntype (new_call, TREE_TYPE (new_decl)); but obviously if gimple_call_fntype and fndecl don't match cloning the mismatched decl isn't of very much help ... (it may just generate more mismatches with mismatching bounds...). > ... > > Martin > >> >> Richard. >> >>> Martin >