Re: [PATCH] ubsan: fix tree-wide -Wmaybe-uninitialized false positives

[Andrey Ryabinin]

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
>>    -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.