https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |msebor at gcc dot gnu.org
--- Comment #17 from Martin Sebor <msebor at gcc dot gnu.org> ---
For the test case in attachment 45096 GCC 11 emits a nicer message:
In file included from header.cpp:5:
In member function ‘info& info::operator=(const info&)’,
inlined from ‘void test(info_t)’ at header.cpp:10:12:
header.h:8:16: warning: ‘copy.info::registered’ is used uninitialized
[-Wuninitialized]
header.cpp: In function ‘void test(info_t)’:
header.cpp:9:12: note: ‘copy’ declared here
In file included from header.cpp:5:
In copy constructor ‘info::info(const info&)’,
inlined from ‘int main()’ at header.cpp:21:9:
header.h:8:16: warning: ‘temp.info::registered’ is used uninitialized
[-Wuninitialized]
header.cpp: In function ‘int main()’:
header.cpp:19:12: note: ‘temp’ declared here
This looks pretty close to optimal to me. The caret location for the
implicitly generated copy assignment is not ideal though. It points to the
class definition like so:
In member function ‘info& info::operator=(const info&)’,
inlined from ‘void test(info_t)’ at pr88175-c0.C.C:12044:12:
pr88175-c0.C.C:12036:16: warning: ‘copy.info::registered’ is used uninitialized
[-Wuninitialized]
12036 | typedef struct info
| ^~~~
pr88175-c0.C.C: In function ‘void test(info_t)’:
pr88175-c0.C.C:12043:12: note: ‘copy’ declared here
12043 | info_t copy;
| ^~~~
In copy constructor ‘info::info(const info&)’,
inlined from ‘int main()’ at pr88175-c0.C.C:12051:9:
pr88175-c0.C.C:12036:16: warning: ‘temp.info::registered’ is used uninitialized
[-Wuninitialized]
12036 | typedef struct info
| ^~~~
pr88175-c0.C.C: In function ‘int main()’:
pr88175-c0.C.C:12050:12: note: ‘temp’ declared here
12050 | info_t temp;
| ^~~~
Pointing to the invocation of the special function might be a better choice.
That should be doable by testing the DECL_ARTIFICIAL bit and using the other
location instead.
The test case in comment #16 isn't diagnosed by GCC 11 at any optimization
level anymore (a regression caused by r158271). I think that's something to
handle separately.
