From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21143 invoked by alias); 11 Nov 2014 16:13:01 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21075 invoked by uid 89); 11 Nov 2014 16:13:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mailout4.w1.samsung.com Received: from mailout4.w1.samsung.com (HELO mailout4.w1.samsung.com) (210.118.77.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (DES-CBC3-SHA encrypted) ESMTPS; Tue, 11 Nov 2014 16:12:59 +0000 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NEV00JA3UI4AK10@mailout4.w1.samsung.com> for gcc@gcc.gnu.org; Tue, 11 Nov 2014 16:15:40 +0000 (GMT) Received: from eusync4.samsung.com ( [203.254.199.214]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 44.C6.24279.78532645; Tue, 11 Nov 2014 16:12:55 +0000 (GMT) Received: from [106.109.129.103] by eusync4.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0NEV00ACWUDIT280@eusync4.samsung.com>; Tue, 11 Nov 2014 16:12:55 +0000 (GMT) Message-id: <54623587.8060403@samsung.com> Date: Tue, 11 Nov 2014 16:13:00 -0000 From: Marat Zakirov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-version: 1.0 To: Richard Biener , Jakub Jelinek Cc: GCC Mailing List , Yury Gribov Subject: Re: [RFC] UBSan unsafely uses VRP References: <5462170F.5040102@samsung.com> <20141111141521.GE5026@tucnak.redhat.com> In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-SW-Source: 2014-11/txt/msg00155.txt.bz2 On 11/11/2014 05:26 PM, Richard Biener wrote: > On Tue, Nov 11, 2014 at 3:15 PM, Jakub Jelinek wrote: >> On Tue, Nov 11, 2014 at 05:02:55PM +0300, Marat Zakirov wrote: >>> I found that UBSan uses vrp pass to optimize generated checks. Keeping in >>> mind that vrp pass is about performance not stability I found example where >>> UBSan may skip true positive. >>> >>> Example came from spec2006 perlbench: >>> >>> int ext; >>> >>> int >>> Perl_do_sv_dump() >>> { >>> int freq[10]; >>> int i; >>> int max = 0; >>> int t = INT_MAX - 20; >>> >>> if (max < ext) >>> max = ext; >>> >>> for (i = 0; i <= max; i++) >>> if (freq[i]) >>> ext = 0; >>> >>> t += i; <<< (*) >>> return t; >>> } >>> >>> vrp pass here sets vrp('i') to [0..10] in assumption that 'freq[i]' wont >>> violate array bound (vrp uses loop iteration number calculation, see >>> adjust_range_with_scev in tree-vrp.c). This means that UBSAN_CHECK_ADD build >>> for (*) should be deleted as redundant (and actually it is deleted by vrp >>> pass). So if at the execution max = 30, freq[5] != 0 uncaught overflow will >>> occur. >> Well, if max is >= 10, then you should get -fsanitize=bounds error already. >> -fsanitize=undefined already disables -faggressive-loop-optimizations, >> perhaps it can also disable other optimizations (I thought deriving number >> of iterations from assuming undefined behavior doesn't occur in loop stmts >> is already guarded by -faggressive-loop-optimizations though). > You could use -fno-strict-overflow ... > >>> There are also some unsafe code in functions >>> ubsan_expand_si_overflow_addsub_check, ubsan_expand_si_overflow_mul_check >>> which uses get_range_info to reduce checks number. As seen before vrp usage >>> for sanitizers may decrease quality of error detection. >> Using VRP is completely intentional there, we don't want to generate too >> slow code if you decide you want to optimize your code (for -O0 VRP isn't >> performed of course). > Indeed. Note that the strict-overflow warnings are already a bad burden > on VRP quality - a way out to me was always to track two lattices, > one assuming strict-overflow and one assuming wrapping overflow. > For strict-overflow warnings you then can compare simplification outcome > against two lattices and warn if the result differs. Instead of that odd > +-INF(OVF) saturation. > > Richard. > >> Jakub >> It is seems that -fsanitize=something do not set flag_aggressive_loop_optimizations to 0 in current GCC version. I made a watchpoint on it but changes after init_options_struct weren't found. I will make fix for both flag_aggressive_loop_optimizationsno-strict-overflow and flag_strict_overflow. --Marat