From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26825 invoked by alias); 18 Nov 2014 07:39:52 -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 26815 invoked by uid 89); 18 Nov 2014 07:39:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oi0-f41.google.com Received: from mail-oi0-f41.google.com (HELO mail-oi0-f41.google.com) (209.85.218.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 18 Nov 2014 07:39:49 +0000 Received: by mail-oi0-f41.google.com with SMTP id a3so5527489oib.28 for ; Mon, 17 Nov 2014 23:39:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m9f6YVtngwzMJZIKL5sqFu1Htj6hoXG8W1fe4VXkXJk=; b=V8sAjpUZjjz7nTc45IVZf4UdyO2hAetqNVtT3CrROFbWXvHO+VBFIlRnPUhKBUexEx MdyQy2YdhztEqB2jDqPPSeOSvneEVd8t/rR4wtUxR3Q5vpLSH2rSnAaxPK2Bb+KhCblx f12uKo5Kdcrxe+r6t6eLLRftuQMItl2PrwK1Em4Gd56Nm2mwSeD8nQzw6oX3d2C89OS5 f6gwHHN1SPvfayCd5H3oKxMIbA/djz7ejN5biDVNAk7ynSYytOgft/oMJtx6112CSX5D hkbEntM/SwFJSbwL8mZ42t9gF7gh3pYUy4KcbX8/cksJrwlNwBxqct1xue+wDQN6ZniO b6SQ== X-Gm-Message-State: ALoCoQkcvjOGwaGiMBoPV1lDZn3W69s/rLGAp1p6L2tNGerlKlC15rNTE0vNdwvbDGNxAlmFm7AD MIME-Version: 1.0 X-Received: by 10.202.191.10 with SMTP id p10mr27216053oif.32.1416296387591; Mon, 17 Nov 2014 23:39:47 -0800 (PST) Received: by 10.182.143.71 with HTTP; Mon, 17 Nov 2014 23:39:47 -0800 (PST) In-Reply-To: <20141118064740.GE1745@tucnak.redhat.com> References: <20140930054027.GJ17454@tucnak.redhat.com> <542A56C0.2030506@samsung.com> <20140930173340.GI1986@tucnak.redhat.com> <20140930173913.GJ1986@tucnak.redhat.com> <543BADAB.4090000@samsung.com> <20141017161334.GF10376@tucnak.redhat.com> <20141118064740.GE1745@tucnak.redhat.com> Date: Tue, 18 Nov 2014 08:29:00 -0000 Message-ID: Subject: Re: [PATCH] -fsanitize-recover=list From: Alexey Samsonov To: Jakub Jelinek Cc: Yury Gribov , Marek Polacek , GCC Patches , Dmitry Vyukov , Konstantin Serebryany Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-11/txt/msg02208.txt.bz2 On Mon, Nov 17, 2014 at 10:47 PM, Jakub Jelinek wrote: > > On Mon, Nov 17, 2014 at 06:40:00PM -0800, Alexey Samsonov wrote: > > I've just prepared a patch implementing -fsanitize-recover= in > > Clang (http://reviews.llvm.org/D6302), writing here to make sure we're > > on > > the same page w.r.t. flag semantics: > > > > * -fsanitize-recover: Enable recovery for all checks enabled by > > -fsanitize= which support it. > > * -fno-sanitize-recover: Disable recovery for all checks. > > That is not what I think we've agreed on and what is implemented in GCC. > -fsanitize-recover only enables recovery of the undefined plus > undefined-like sanitizers, in particular it doesn't enable recover from > kernel-address, because -fsanitize-recover should be a deprecated option > and kernel-address never used it before. Hm, indeed, I messed it up. In the older thread we agree that plain -f(no-)sanitize-recover should be a deprecated synonym for the current meaning of these flags, which only specify recoverability for UBSan-related checks :-/ Has GCC already shipped with existing implementation? I'm just curious if it's convenient to have flags that would enable/disable recovery for all sanitizers (analogous to -Werror flags which exist in a standalone form, but may accept specific warnings, so that one can write "$(CC) foo.cc -Wno-error -Werror=sign-compare" > So, in GCC -fsanitize-recover stands for > -fsanitize-recover=undefined,float-divide-by-zero,float-cast-overflow > and -fno-sanitize-recover stands for > -fno-sanitize-recover=undefined,float-divide-by-zero,float-cast-overflow > > > * -fsanitize-recover=: Enable recovery for all selected checks > > or group of checks. It is forbidden to list unrecoverable sanitizers > > here (e.g., "-fsanitize-recover=address" will produce an error). > > We only error on > -fsanitize-recover=address > -fsanitize-recover=thread > -fsanitize-recover=leak Right, it's a good idea to error on sanitizer kinds we don't have recovery for. I will add the errors for TSan/MSan/LSan etc. > but not say on > -fsanitize-recover=unreachable > which is part of undefined; unreachable isn't recoverable silently. > Likewise -fsanitize-recover=return. Otherwise one couldn't use > -fsanitize-recover=undefined which is useful. Can't this be fixed by checking the actual values of -fsanitize-recover= flag before expanding the sanitizer groups (i.e. turning "undefined" into "null,unreachable,return,....")? We should probably be able to distinguish between -fsanitize-recover=undefined, and -fsanitize-recover=unreachable,. In the first case we can enable recovery for all parts of "undefined" that support it. In the second, we can produce an error as user explicitly tried to enable recovery for sanitizer that doesn't support it. This is only a diagnostic quality issue, though. > > > * -fno-sanitize-recover=: Disable recovery for selected checks > > or group of checks. > > Jakub -- Alexey Samsonov, Mountain View, CA