Re: Adding -Wshadow=local to gcc build rules
On 9/18/19 3:08 PM, Bernd Edlinger wrote: > Hi, > > I'm currently trying to add -Wshadow=local to the gcc build rules. > I started with -Wshadow, but gave up that idea immediately. > > As you could expect the current code base has plenty of shadowed > local variables. Most are trivial to resolve, some are less trivial. > I am not finished yet, but it is clear that it will be a rather big > patch. > > I would like to ask you if you agree that would be a desirable step, > in improving code quality in the gcc tree. > > > Thanks > Bernd. > Hurray!!! The build is now working with -Wshadow=local and I need to sort out the changes. I hope you are gonna like it :-) Currently it is a 600K patch file all together. Some parts are not trivial at all, but I hope it will pay off in more easy to follow code in various places and less errors in new code. Also one or two real bugs were hiding near the shadowed variable. Most of which are of the obvious kind where, one variable is shadowed by another one, and either the inner or the outer variable need to be renamed from name to name1, or i to j/k, or p to q, or x to y. Sometimes also to name2 or name3, etc. If it is a location_t I follow common practice that loc is renamed to loc0. I avoid renaming a parameter, unless it causes much more changes. Also when a renamed variable appears to be named in a comment I also update the comment. I tried to make the change smaller if possible, rather often the shadowed variable is of the exact same type, and no longer used at the place where the variable is declared again. I consider "unsigned" and "unsigned int" as too different to re-use the variable (or parameter). This means I did consider the control flow and data flow around each shadowed variable if avoiding the duplicate variable is safe. Unless there is disagreement I will go ahead and commit trivial parts after careful regression-testing under the obvious rule. I did also try to build a lot of cross compilers to make sure that the targets do not break when the warning is enabled. But it is nevertheless rather likely that you will see some fall-out once the warning will be enabled. So far each target (except tilepro) needed at least a few changes. This is the list of changed files: M ada/gcc-interface/decl.c M ada/gcc-interface/trans.c M asan.c M attribs.c M auto-inc-dec.c M bb-reorder.c M brig/brigfrontend/brig-basic-inst-handler.cc M brig/brigfrontend/brig-code-entry-handler.cc M brig/brigfrontend/brig-function-handler.cc M brig/brigfrontend/brig-util.cc M builtins.c M c/c-decl.c M c/c-parser.c M c/c-typeck.c M c/gimple-parser.c M c-family/c-ada-spec.c M c-family/c-common.c M c-family/c-cppbuiltin.c M c-family/c-lex.c M c-family/c-omp.c M caller-save.c M calls.c M cfg.c M cfgbuild.c M cfgcleanup.c M cfgexpand.c M cfgloopmanip.c M cfgrtl.c M cgraph.c M cgraph.h M cgraphbuild.c M cgraphclones.c M cgraphunit.c M combine.c M config/aarch64/aarch64.c M config/aarch64/cortex-a57-fma-steering.c M config/aarch64/falkor-tag-collision-avoidance.c M config/alpha/alpha.c M config/arm/arm.c M config/csky/csky.c M config/elfos.h M config/i386/i386-expand.c M config/i386/i386-features.c M config/i386/i386-options.c M config/i386/i386.c M config/i386/x86-tune-sched.c M config/ia64/ia64.c M config/m68k/m68k.c M config/m68k/m68k.md M config/microblaze/microblaze.c M config/mips/mips.c M config/nios2/nios2.c M config/pa/pa.c M config/pa/pa.md M config/rs6000/rs6000-call.c M config/rs6000/rs6000-logue.c M config/rs6000/rs6000-p8swap.c M config/rs6000/rs6000.c M config/rs6000/rs6000.md M config/s390/s390.c M config/sh/sh.c M config/sparc/sparc.c M config/xtensa/xtensa.c M configure M configure.ac M cp/call.c M cp/class.c M cp/constexpr.c M cp/constraint.cc M cp/cp-gimplify.c M cp/decl.c M cp/decl2.c M cp/error.c M cp/friend.c M cp/init.c M cp/method.c M cp/name-lookup.c M cp/parser.c M cp/pt.c M cp/rtti.c M cp/semantics.c M cp/typeck.c M cp/typeck2.c M cprop.c M cse.c M cselib.c M d/d-codegen.cc M d/decl.cc M d/dmd/doc.c M d/dmd/dscope.c M d/dmd/initsem.c M d/expr.cc M defaults.h M df-problems.c M df-scan.c M diagnostic-show-locus.c M doc/invoke.texi M dse.c M dumpfile.h M dwarf2cfi.c M dwarf2out.c M emit-rtl.c M expmed.c M expr.c M final.c M fold-const.c M fortran/arith.c M fortran/class.c M fortran/decl.c M
Re: Adding -Wshadow=local to gcc build rules
Hi! On Wed, Sep 18, 2019 at 01:08:50PM +, Bernd Edlinger wrote: > I'm currently trying to add -Wshadow=local to the gcc build rules. > I started with -Wshadow, but gave up that idea immediately. > > As you could expect the current code base has plenty of shadowed > local variables. Most are trivial to resolve, some are less trivial. > I am not finished yet, but it is clear that it will be a rather big > patch. It shouldn't be a big patch. It should be a biggish collection of small patches, most of which are trivial and obvious and you can just commit without further approval! Segher
Re: Adding -Wshadow=local to gcc build rules
On Fri, Sep 20, 2019, 2:21 PM Bernd Edlinger
wrote:
> On 9/19/19 12:19 PM, Richard Biener wrote:
> > On Wed, Sep 18, 2019 at 3:09 PM Bernd Edlinger
> > wrote:
> >>
> >> Hi,
> >>
> >> I'm currently trying to add -Wshadow=local to the gcc build rules.
> >> I started with -Wshadow, but gave up that idea immediately.
> >>
> >> As you could expect the current code base has plenty of shadowed
> >> local variables. Most are trivial to resolve, some are less trivial.
> >> I am not finished yet, but it is clear that it will be a rather big
> >> patch.
> >>
> >> I would like to ask you if you agree that would be a desirable step,
> >> in improving code quality in the gcc tree.
> >
> > I wonder if -Wshadow=compatible-local is easier to achieve?
> >
>
> I tried that and it does not make a big difference, while
> it misses for instance:
>
> * gcc/c-family/c-ada-spec.c (dump_ada_macros)
> unsigned char *s, shadowed by const unsigned char *s. :-/
>
> On the other hand, -Wshadow=global is a lot more difficult,
> because we have lots of globals, for instance:
>
> context.h:
> /* The global singleton context aka "g".
>(the name is chosen to be easy to type in a debugger). */
> extern gcc::context *g;
>
> But unfortunately Wshadow=local does not find class members
> shadowed by local variable, which happens for instance in
> wide-int
>
> With -Wshadow, I had to change this in wide-int.h:
>
> Index: gcc/wide-int.h
> ===
> --- gcc/wide-int.h (revision 275545)
> +++ gcc/wide-int.h (working copy)
> @@ -648,9 +648,9 @@ namespace wi
> storage_ref () {}
> storage_ref (const HOST_WIDE_INT *, unsigned int, unsigned int);
>
> -const HOST_WIDE_INT *val;
> -unsigned int len;
> -unsigned int precision;
> +const HOST_WIDE_INT *m_val;
> +unsigned int m_len;
> +unsigned int m_precision;
>
>
> So this change was not necessary for -Wshadow=local, although
> I would think that, shadowing class members is not much different from
> shadowing a local scope.
>
> Not sure if shadowing class members should be part of -Wshadow=local
> instead of -Wshadow=global.
>
That would make sense to me.
>
Re: Adding -Wshadow=local to gcc build rules
On 9/19/19 12:19 PM, Richard Biener wrote:
> On Wed, Sep 18, 2019 at 3:09 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> I'm currently trying to add -Wshadow=local to the gcc build rules.
>> I started with -Wshadow, but gave up that idea immediately.
>>
>> As you could expect the current code base has plenty of shadowed
>> local variables. Most are trivial to resolve, some are less trivial.
>> I am not finished yet, but it is clear that it will be a rather big
>> patch.
>>
>> I would like to ask you if you agree that would be a desirable step,
>> in improving code quality in the gcc tree.
>
> I wonder if -Wshadow=compatible-local is easier to achieve?
>
I tried that and it does not make a big difference, while
it misses for instance:
* gcc/c-family/c-ada-spec.c (dump_ada_macros)
unsigned char *s, shadowed by const unsigned char *s. :-/
On the other hand, -Wshadow=global is a lot more difficult,
because we have lots of globals, for instance:
context.h:
/* The global singleton context aka "g".
(the name is chosen to be easy to type in a debugger). */
extern gcc::context *g;
But unfortunately Wshadow=local does not find class members
shadowed by local variable, which happens for instance in
wide-int
With -Wshadow, I had to change this in wide-int.h:
Index: gcc/wide-int.h
===
--- gcc/wide-int.h (revision 275545)
+++ gcc/wide-int.h (working copy)
@@ -648,9 +648,9 @@ namespace wi
storage_ref () {}
storage_ref (const HOST_WIDE_INT *, unsigned int, unsigned int);
-const HOST_WIDE_INT *val;
-unsigned int len;
-unsigned int precision;
+const HOST_WIDE_INT *m_val;
+unsigned int m_len;
+unsigned int m_precision;
So this change was not necessary for -Wshadow=local, although
I would think that, shadowing class members is not much different from
shadowing a local scope.
Not sure if shadowing class members should be part of -Wshadow=local
instead of -Wshadow=global.
Bernd.
Re: Adding -Wshadow=local to gcc build rules
On Wed, Sep 18, 2019 at 3:09 PM Bernd Edlinger wrote: > > Hi, > > I'm currently trying to add -Wshadow=local to the gcc build rules. > I started with -Wshadow, but gave up that idea immediately. > > As you could expect the current code base has plenty of shadowed > local variables. Most are trivial to resolve, some are less trivial. > I am not finished yet, but it is clear that it will be a rather big > patch. > > I would like to ask you if you agree that would be a desirable step, > in improving code quality in the gcc tree. I wonder if -Wshadow=compatible-local is easier to achieve? Richard. > > > Thanks > Bernd.
Re: Adding -Wshadow=local to gcc build rules
> "Bernd" == Bernd Edlinger writes: Bernd> I'm currently trying to add -Wshadow=local to the gcc build rules. Bernd> I started with -Wshadow, but gave up that idea immediately. Bernd> As you could expect the current code base has plenty of shadowed Bernd> local variables. Most are trivial to resolve, some are less trivial. Bernd> I am not finished yet, but it is clear that it will be a rather big Bernd> patch. Bernd> I would like to ask you if you agree that would be a desirable step, Bernd> in improving code quality in the gcc tree. We did this in gdb and it was worthwhile. According to my notes, it found 3 real bugs (though one was by chance). You can see what else we tried here: https://tromey.com/blog/?p=1035 Tom
Re: Adding -Wshadow=local to gcc build rules
On 9/18/19 3:08 PM, Bernd Edlinger wrote: > Hi, > > I'm currently trying to add -Wshadow=local to the gcc build rules. > I started with -Wshadow, but gave up that idea immediately. > > As you could expect the current code base has plenty of shadowed > local variables. Most are trivial to resolve, some are less trivial. > I am not finished yet, but it is clear that it will be a rather big > patch. > > I would like to ask you if you agree that would be a desirable step, > in improving code quality in the gcc tree. > > > Thanks > Bernd. > Hello. I did the very same for godot project some time ago: https://github.com/godotengine/godot/pull/25853 I fully support such a patch. Martin
