From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31179 invoked by alias); 17 Sep 2014 14:27:11 -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 31126 invoked by uid 89); 17 Sep 2014 14:27:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 17 Sep 2014 14:27:09 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8HER6bU009769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 17 Sep 2014 10:27:07 -0400 Received: from [10.10.116.27] ([10.10.116.27]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8HER5dL026441; Wed, 17 Sep 2014 10:27:05 -0400 Message-ID: <54199A36.1080604@redhat.com> Date: Wed, 17 Sep 2014 14:27:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Jakub Jelinek , Marek Polacek CC: gcc-patches@gcc.gnu.org Subject: Re: [RFC PATCH] -fsanitize=vptr instrumentation References: <20140916145644.GZ17454@tucnak.redhat.com> In-Reply-To: <20140916145644.GZ17454@tucnak.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg01373.txt.bz2 On 09/16/2014 10:56 AM, Jakub Jelinek wrote: > vptr-5.C is one Jason mailed me yesterday, clang++ doesn't instrument this > and g++ right now doesn't either, build_static_cast_1 certainly isn't called > in that case, and I must say I have no idea what should be checked there, > where etc. What needs to be checked is conversion (in this case implicit) to a virtual base; if the vptr doesn't point to a vtable that has the appropriate vbase offset, we should complain. virtual base conversions are implemented in build_base_path under if (virtual_access). > vptr-6.C shows where the this optimization is performed and where it isn't > (clang++ has 10 instrumentations in T::h and 1 in S::l, g++ has fewer than > that, but not 0 in T::h (1 in S::l is right and needed I think)). I agree that 0 is enough for T::h and 1 for S::l. > I hope all of f[1-6] is invalid, I really don't see how we could instrument > member accesses otherwise (we'd need to limit to not taking address of it); > NULL pointer shouldn't point at a valid object. I don't see anything in the standard saying that these are undefined, only that trying to access the (non-)object pointed to is undefined. It would be undefined if a conversion to virtual base were involved, i.e. struct V: virtual R { }; // undefined if p doesn't point to a V because of the conversion to // virtual base R int* f7 (V* p) { return &p->r; } These conditions were loosened in C++11 by DRs 597 and 1531; before that it was reasonable to regard f[1-6] as undefined, and perhaps clang is using the earlier interpretation. > + TREE_SIDE_EFFECTS (cond) = 1; ... > + TREE_SIDE_EFFECTS (hash) = 1; Why do you need to set TREE_SIDE_EFFECTS on these? > + if (current_function_decl == NULL_TREE > + || lookup_attribute ("no_sanitize_undefined", > + DECL_ATTRIBUTES (current_function_decl))) > + return NULL_TREE; When would this be called outside a function? If for namespace-scope variable initializers, I'd think we do want instrumentation. > + /* T t; t.foo (); doesn't need instrumentation, if the type is known. */ > + if (is_addr > + && TREE_CODE (op) == ADDR_EXPR > + && DECL_P (TREE_OPERAND (op, 0)) > + && same_type_p (type, > + TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (op, 0))))) > + return NULL_TREE; You might want to use resolves_to_fixed_type_p in the optimizations. Jason