On 01/26/2016 12:41 AM, Andrew Morton wrote: > On Mon, 25 Jan 2016 19:01:34 +0300 Andrey Ryabinin <[email protected]> > 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.
