Re: [PATCH] ubsan: fix tree-wide -Wmaybe-uninitialized false positives
From: Andrey Ryabinin
Date: Tue Jan 26 2016 - 12:02:31 EST
On 01/26/2016 12:41 AM, Andrew Morton wrote:
> On Mon, 25 Jan 2016 19:01:34 +0300 Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx> 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
> 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.