For this C++ code: $ more bug790.cc int *metricp; void s88() { int distance; metricp = &distance; } $ Does this with recent gcc trunk: $ /home/dcb/gcc/results/bin/gcc -c -O2 -D_FORTIFY_SOURCE=2 -Wall bug790.cc bug790.cc: In function ‘void s88()’: bug790.cc:4:11: warning: storing the address of local variable ‘distance’ in ‘metricp’ [-Wdangling-pointer=] 4 | metricp = &distance; | ~~~~~~~~^~~~~~~~~~~ bug790.cc:3:7: note: ‘distance’ declared here 3 | int distance; | ^~~~~~~~ bug790.cc:1:6: note: ‘metricp’ declared here 1 | int *metricp; | ^~~~~~~ bug790.cc:4:11: warning: storing the address of local variable ‘distance’ in ‘metricp’ [-Wdangling-pointer=] 4 | metricp = &distance; | ~~~~~~~~^~~~~~~~~~~ bug790.cc:3:7: note: ‘distance’ declared here 3 | int distance; | ^~~~~~~~ bug790.cc:1:6: note: ‘metricp’ declared here 1 | int *metricp; | ^~~~~~~ $ I've no idea why the warning is generated, the code looks legal to me and I've no idea why the warning is duplicated.
>I've no idea why the warning is generated, the code looks legal to me The warning is generated even though the code is valid, if someone deferences metricp after the call to s88, the code becomes undefined. It is designed to warn about that case. Why the warning is duplicated I have no idea.
(In reply to Andrew Pinski from comment #1) > >I've no idea why the warning is generated, the code looks legal to me > > The warning is generated even though the code is valid, if someone > deferences metricp after the call to s88, the code becomes undefined. A warning for valid code is IMHO really bad. It would be a better warning if it only happened when the pointer is dereferenced. As is, I've got to find every occurrence of this warning and manually check for a problem. I think 90% of the time, it going to be legal code. > Why the warning is duplicated I have no idea. Righto.
It's a style warning as much as a correctness one (like most warnings are). A good programmers style workaround would be int *metricp; void s88() { int distance; metricp = &distance; metricp = NULL; } but I realize that's tedious and wasted cycles in the end (when all bogus users are identified and fixed). I do question -Wdangling-pointer being included in -Wall, it's at most -Wextra category, if at all.
I just tried compiling a recent linux kernel with the new gcc trunk and the warning appeared seven times. Only one of them was a proper bug, which I have reported. The rest were false positives. So this warning occasionally produces something useful, so it can't be simply temporarily ignored until it works properly. I suggest it gets taken out of -Wall and -Wextra until it works a bit better.
This form of the warning implements a commonly requested feature missing from -Wreturn-local-addr (also included in -Wall): allowing the address of a local variable to escape the scope of the function. Both warnings are issued for strictly valid code. See for example pr26671, pr49974, pr54301, pr82520, pr84544, pr90905 for related requests (the initial implementation is too simplistic to fully handle all these but eventually it should). A case very similar to the one in comment #0 is documented in the manual: In the following function the store of the address of the local variable x in the escaped pointer *p also triggers the warning. void g (int **p) { int x = 7; *p = &x; // warning: storing the address of a local variable in *p } The duplication is (of course) a bug. Since the warning works as intended and documented (there's no false positive) I'm going to resolve this report as invalid. If you want to request a separate level to control this aspect please open an enhancement request (I'm open to implementing it). If you want to remove this level from -Wall, please do the same (though I don't support that request).