On Mon, Mar 19, 2018 at 05:53:09PM +0000, Ramsay Jones wrote: > This series removes all 'self-initialised' variables (ie. <type> var = var;). > This construct has been used to silence gcc '-W[maybe-]uninitialized' warnings > in the past [1]. Unfortunately, this construct causes warnings to be issued by > MSVC [2], along with clang static analysis complaining about an 'Assigned value > is garbage or undefined'. The number of these constructs has dropped over the > years (eg. see [3] and [4]), so there are currently only 6 remaining in the > current codebase. As demonstrated below, 5 of these no longer cause gcc to > issue warnings. Great. I'm happy to see these going away, and thanks for all the careful digging. > If we now add a patch to remove all self-initialization, which would be the > first patch plus the obvious change to 'saved_namelen' in read-cache.c, then > note the warnings issued by various compilers at various optimization levels > on several different platforms [5]: > > O0 O1 O2 O3 Os Og > 1) gcc 4.8.3 | - 1,20 1 1,18-19 1-4,21-23 1,5-17 > 2) gcc 4.8.4 | - 1,20 1 1 1-4,21-23 1,5-8,10-13,15-16 > 3) clang 3.4 | - - - - - n/a > 4) gcc 5.4.0 | - 1 1 1 1,3-4,21 1,5-8,10-13,16-16 > 5) clang 3.8.0 | - - - - - n/a > 6) gcc 5.4.0 | - 1 1 1 1-4 1,5-17 > 7) clang 3.8.0 | - - - - - n/a > 8) gcc 6.4.0 | - 1 1 1,18-19 1,4 1,5-17 > 9) clang 5.0.1 | - - - - - - > 10) gcc 7.2.1 | - 1 1 1 1,4 1,5-17 So I guess this could create headaches for people using DEVELOPER=1 on as ancient a compiler as 4.8.4, but most other people should be OK. I think I can live with that as a cutoff, and the Travis builds should work there. (And if we do the detect-compiler stuff from the other nearby thread, somebody who cares can even loosen the warnings for those old gcc versions). I'm neglecting anybody doing -O3 or -Os here, but IMHO those are sufficiently rare that the builder can tweak their own settings. I wonder if people use -Og, though? I don't (I usually do -O0 for my edit-compile-debug cycle). -Peff
