From patchwork Wed Jul 31 12:25:44 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Polacek X-Patchwork-Id: 263690 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 7F1342C00AB for ; Wed, 31 Jul 2013 22:26:03 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=sbg0aO52boIB1TV9j QoB//JN3205/iOXoo333DU8zcJOHhQdr/m/yQKoNBQOl+ACOFG5Nhg9vGFL6ozya nbUDQYojWobbbk0b6EOo9W0VjSrKtU+SC1+YueVqXKLuFieXhy1y5smT7ejRor/U 2TiqsU9hBGQCcGNVAsk+b2syvM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=5nLzCXM6B7uJqDC99AKQP1l rDXE=; b=smqEdUWOYvDGt8UG437Xzv2RaWy4PN2Yv0WJzYFzDQzoEoahr1qGaMs wDIEN8iJGU9jrOKMEORB6ZaZ3zaeGTdYOukiQZH5IGRggh6o46CKpoVmoF1W7lj9 D75Jqg/PzgEKqz4MfIdm7frw9/jk8YWgYbAbjzhMgLdouYi3RdhE= Received: (qmail 25551 invoked by alias); 31 Jul 2013 12:25:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 25528 invoked by uid 89); 31 Jul 2013 12:25:57 -0000 X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL, BAYES_50, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL, RDNS_NONE, SPF_HELO_PASS, SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 31 Jul 2013 12:25:56 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6VCPmlo023122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 08:25:48 -0400 Received: from redhat.com (ovpn-116-37.ams2.redhat.com [10.36.116.37]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6VCPiM1020319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 31 Jul 2013 08:25:46 -0400 Date: Wed, 31 Jul 2013 14:25:44 +0200 From: Marek Polacek To: "Joseph S. Myers" Cc: GCC Patches , Jakub Jelinek , Jeff Law , Jason Merrill Subject: Re: Request to merge Undefined Behavior Sanitizer in Message-ID: <20130731122544.GR17022@redhat.com> References: <20130725153227.GC32538@redhat.com> <20130725153500.GD32538@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) On Thu, Jul 25, 2013 at 10:43:30PM +0000, Joseph S. Myers wrote: > On Thu, 25 Jul 2013, Marek Polacek wrote: > > > +@item -fsanitize=undefined > > +Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector > > +Various computations will be instrumented to detect > > +undefined behavior, e.g.@: division by zero or various overflows. > > The same issues applies as for bounds-checking options - please give > sufficient information in the documentation for a user to be able to judge > the trade-offs between this and -ftrapv (for example). Ok, I've commited a patch which hopefully makes the documentation better: > It should also be clear how this interacts with -fwrapv. I'd say that > -fwrapv makes the semantics of overflow in signed-integer arithmetic no > longer undefined (of course division by zero is still undefined) and so > should mean such overflows aren't warned for. Now, you don't currently > have any checks this would affect (given that INT_MIN / -1 and INT_MIN % > -1 don't currently work reliably with -fwrapv anyway), but the intention > should be clear for when overflow checks are added. Yes, I agree. When the signed overflows checks are in, we shouldn't sanitize signed overflows when -fwrapv is in effect. Marek --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -5150,8 +5150,11 @@ See @uref{http://code.google.com/p/data-race-test/wiki/ThreadSanitizer} for @item -fsanitize=undefined Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector -Various computations will be instrumented to detect -undefined behavior, e.g.@: division by zero or various overflows. +Various computations will be instrumented to detect undefined behavior +at runtime, e.g.@: division by zero or various overflows. +While @option{-ftrapv} causes traps for signed overflows to be emitted, +@option{-fsanitize=undefined} gives a diagnostic message. +This currently works only for the C family of languages. @item -fdump-final-insns@r{[}=@var{file}@r{]} @opindex fdump-final-insns