On 10/4/19 10:23 PM, Jeff Law wrote: > On 10/4/19 12:24 PM, Bernd Edlinger wrote: >> Hi, >> >> this macro caused -Wshadow=local warnings in varasm.c with >> the microblaze target. >> >> >> Only built a bare metal cross compiler that was able to compile >> libgcc for that target. >> >> Is it OK for trunk? >> >> >> Thanks >> Bernd. >> >> >> >> patch-wshadow-defaults.diff >> >> 2019-10-04 Bernd Edlinger <bernd.edlin...@hotmail.de> >> >> * defaults.h (ASM_OUTPUT_ASCII): Rename local vars in macro. >> Remove variable hiding code. > ISTM this would be better done by creating a target hook with the > defaults.h implementation as the default implementation and converting > the dozen or so backends that need to override the default. >
Yes, absolutely, but I need to do some nit-picking here, in order to make any progress at all. It is out of my scope to do that macro conversion for all ports at the same time when I just want to add a warning. I believe however, that using names in the reserved in the global namespace _ followed by lowercase letter, is still an improvement, as that is much less likely to be used in normal code. > More generally, shadowing problems are inherent with macro usage and I > suspect pervasive due to the original GCC style of writing far too much > code in macros. > This macro is a bit special, in that it is insisting in shadowing local variables purposefully. I call that childish... > Rather then burning a lot of time renaming variables, which still have > shadowing potential that we should be turning all the macro crap into > real functions. > Jeff, this is just the beginning. I have sent so far just about 10% of all changes that I have in my tree. I will send more patches soon, but I need some more time to split the changes up in chunks that are not too big to be sent to this list, and write the proper change logs. Current situation is this: We have lots of 1000+ line functions that shadow variables all the time. I believe nobody did that on purpose, but currently you cannot know, if you assign a value to a variable with whatever name in any function and you see the same variable somewhere later in that function that it is still the same variable. For clarifying the data flow it does not matter if I change name to name1 or some_other_name. I use /name1 in vi anyway. After this is changed, you will always know that once you assing a variable it will have that value until you assign the same variable with the same name again, then it will be the new value, but currently the old value can pop up again. I know these are not very good names: int i, j, k; int i1, i2, i3; In general a good name should not just repeat the data type of the variable, but the intended use. for instance: int idx; would be better, since I know by that name that idx will be used as an array index. But it should also not be too long, mind the 80-column rule. I believe finding a good name is often a truly challenging task of its own. However I think, the amount of changes that I have to do just to get every target with every language, with -Wshadow=local boot-strap without error, makes it impossible to think of achieving a second goal like that, at the same time. After all this is a technical debt that accumulated for 20+ Years now. Bernd.
