From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19166 invoked by alias); 3 Oct 2014 18:54:48 -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 19157 invoked by uid 89); 3 Oct 2014 18:54:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 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-f45.google.com Received: from mail-oi0-f45.google.com (HELO mail-oi0-f45.google.com) (209.85.218.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 03 Oct 2014 18:54:47 +0000 Received: by mail-oi0-f45.google.com with SMTP id i138so1208778oig.18 for ; Fri, 03 Oct 2014 11:54:45 -0700 (PDT) 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=ktbUGt+2RER3+eJ++JDMv7xqzQCCdM1RoycKsLDWUGw=; b=HuPW1wwRP4qnPp821OKAPyiLJ4P5mTGigQq11lhlRPu4iLyQtGqZk/sCh0kCumfAGB 6wlQvfbC/ORQX4G+pw+a0cfRaAFVkxWLSqmB30BQxeaA2WhWCQhDmwjU9J+i79/nsntQ 4y1/5tGfQKkMLXS00uhVj/ox358wGrlyDq4syQI4BK+wwpxbhKWIksJlVeh/pWGBywZx gLaz3ytr47zknB5EPeD0RmftuuXh4DzvDekQrP1LGjdv5/nSIXDHYXMuhQVIzteAkghe G5yxPXMDb+Isu5laqzwUEocAQav6icbzL93zmRPfV9FnQe1UA3YNNk2wZ/lteb40sRFN eG4Q== X-Gm-Message-State: ALoCoQkKIkU/LPqB6YLg28vXWsr2P26x754R0bFzHaPjlhF6BKPV3gISslK4ntIfiX57onFFGBtT MIME-Version: 1.0 X-Received: by 10.182.33.99 with SMTP id q3mr9498841obi.28.1412362484992; Fri, 03 Oct 2014 11:54:44 -0700 (PDT) Received: by 10.182.143.71 with HTTP; Fri, 3 Oct 2014 11:54:44 -0700 (PDT) In-Reply-To: <20141002055819.GY1986@tucnak.redhat.com> References: <20140929231720.GI17454@tucnak.redhat.com> <20140930054027.GJ17454@tucnak.redhat.com> <542A56C0.2030506@samsung.com> <20140930173340.GI1986@tucnak.redhat.com> <20140930173913.GJ1986@tucnak.redhat.com> <20141002055819.GY1986@tucnak.redhat.com> Date: Fri, 03 Oct 2014 18:54:00 -0000 Message-ID: Subject: Re: [PATCHv3][PING] Enable -fsanitize-recover for KASan From: Alexey Samsonov To: Jakub Jelinek Cc: Yury Gribov , Konstantin Serebryany , GCC Patches , Dmitry Vyukov , Andrey Ryabinin , Konstantin Khlebnikov Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-10/txt/msg00342.txt.bz2 On Wed, Oct 1, 2014 at 10:58 PM, Jakub Jelinek wrote: > On Wed, Oct 01, 2014 at 04:21:29PM -0700, Alexey Samsonov wrote: >> Speaking of plain -f(no-)sanitize-recover - it would probably be >> better to change the semantics of this flag, >> so that "-f(no-)?sanitize-recover" means "enable(disable) recovery for >> all sanitizers enabled at this point". >> That is, it would be pretty much like -Werror flag. >> >> For example, >> "-fsanitize=undefined -fsanitize=address -fno-sanitize-recover" >> would mean "run UBSan and ASan and don't recover from errors". > > That would change behavior, e.g. for > -fsanitize=undefined,address -fsanitize-recover > would suddenly enable recovery from asan errors while previously > they wouldn't be recovering. > > GCC has not shipped with the -fsanitize-recover flag yet (we have just > vendor backport of it), so if you don't mind changing behavior for clang > users, I can live with that. Yes, I think so. -fsanitize-recover was not documented in Clang user manual. > Would the default still be > -fsanitize-recover=undefined,kernel-address -fno-sanitize-recover=address ? Yes. -- Alexey Samsonov, Mountain View, CA