From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934729AbcAZRC2 (ORCPT ); Tue, 26 Jan 2016 12:02:28 -0500 Received: from mx2.parallels.com ([199.115.105.18]:56318 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933530AbcAZRCZ (ORCPT ); Tue, 26 Jan 2016 12:02:25 -0500 Subject: Re: [PATCH] ubsan: fix tree-wide -Wmaybe-uninitialized false positives To: Andrew Morton References: <201601251528.rosikkYN%fengguang.wu@intel.com> <1453737694-19138-1-git-send-email-aryabinin@virtuozzo.com> <20160125134136.cee4919a8453c4753f177c3b@linux-foundation.org> CC: , , From: Andrey Ryabinin Message-ID: <56A7A6DC.1010605@virtuozzo.com> Date: Tue, 26 Jan 2016 20:03:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160125134136.cee4919a8453c4753f177c3b@linux-foundation.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: US-EXCH2.sw.swsoft.com (10.255.249.46) To US-EXCH.sw.swsoft.com (10.255.249.47) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/26/2016 12:41 AM, Andrew Morton wrote: > On Mon, 25 Jan 2016 19:01:34 +0300 Andrey Ryabinin wrote: > >> -fsanitize=* options makes GCC less smart than usual and increase number >> of 'maybe-uninitialized' false-positives. So this patch does two things: >> * Add -Wno-maybe-uninitialized to CFLAGS_UBSAN which will disable all >> such warnings for instrumented files. >> * Remove CONFIG_UBSAN_SANITIZE_ALL from all[yes|mod]config builds. So >> the all[yes|mod]config build goes without -fsanitize=* and still with >> -Wmaybe-uninitialized. > > hm, that's a bit sad. > > We have no means of working out whether we should re-enable > maybe-uninitialized for later gcc's, as they become smarter about this. > What do we do, just "remember" to try it later on? > I don't see anything bad about it. Note, that CONFIG_UBSAN_SANITIZE_ALL=y *only* adds -fsanitize=* to CFLAGS and this patch removes only CONFIG_UBSAN_SANITIZE_ALL from allyesconfig, but not the CONFIG_UBSAN. So now, we do allyesconfig build without CONFIG_UBSAN_SANITIZE_ALL (iow without -fsantize=*), but still with CONFIG_UBSAN=y. Which means that we still build lib/ubsan.c (and with -Wmaybe-uninitialized). > Do you know if this issue is on the gcc developer' radar? > I don't know, but it's unlikely that something will be changed here. -Wmaybe-uninitialized will always be prone to false-positives, simply by definition of it(if GCC could prove that variable is uninitialized it will issue another warning -Wuninitialized). And since -fsanitize=* causes significant changes in generated code, the influence on -Wmaybe-uninitialized likely will retain.