Bug 42000

Summary: missing -Wuninitialized warning on a user-defined class ctor
Product: gcc Reporter: Martin Sebor <msebor>
Component: c++Assignee: Richard Biener <rguenth>
Severity: normal CC: fang, gcc-bugs, manu, webrown.cpp
Priority: P3    
Version: 4.4.1   
Target Milestone: ---   
Host: Target:
Build: Known to work: 5.3.0
Known to fail: Last reconfirmed: 2017-02-07 00:00:00
Bug Depends on: 79345    
Bug Blocks: 24639    

Description Martin Sebor 2009-11-10 23:36:19 UTC
gcc misses the access to the uninitialized member S::i in the program below
and fails to issue a warning for it.

I would expect to see a warning not only for the access to the member but
also for the definition of the user-defined constructor that fails to
initialize the data member.

$ cat t.cpp && gcc -Wuninitialized -Wall -Wextra -W -c t.cpp
int main () {
    struct S {
        int i;
        S() { }
    } s;

    return s.i;
Comment 1 Jonathan Wakely 2009-11-11 11:50:05 UTC
It would certainly be nice to get warnings about members that are not initialized in the constructor, I don't think GCC currently does that anywhere.

If you add -O then you will get a warning for the use of the member.  It's unfortunate that this warning is missed without optimisation, but -Wuninitialized no longer warns if you use it without -O
Comment 2 Manuel López-Ibáñez 2009-11-19 12:28:46 UTC
I think this is a duplicate of either bug 2972 or bug 19808 or one of the SRA testcases.
Comment 3 Martin Sebor 2017-02-07 17:37:13 UTC
With the top of trunk (GCC 7) the test case in comment #0 isn't diagnosed with -O2 or at any other optimization level.

I suspect this does fall under one of the existing -Wuninitialized bugs.  I'm not sure bug 2972 covers this case.  Just quickly eyeballing the patch in bug 19808, I don't think it's meant to detect this problem either since it's front-end only solution focused solely on dependencies between members in ctor initializer lists.

I'll confirm this for now and if someone finds a pre-existing duplicate it can be closed then.
Comment 4 Richard Biener 2017-03-02 11:02:29 UTC
Do constructors really need to initialize all members??  I would expect a warning for the use of i and I do get that when optimizing (needs inlining of the constructor) and the patch for PR79345.

It also worked with GCC5:

> ../../gcc5-g/gcc/cc1plus  -quiet t.C -Wall -fdump-tree-all-lineno -O
t.C: In function ‘int main()’:
t.C:7:15: warning: ‘s.main()::S::i’ is used uninitialized in this function [-Wuninitialized]
      return s.i;

Let's say "fixed" then, the regression is tracked in PR79345.
Comment 5 Richard Biener 2017-03-02 13:42:37 UTC
Author: rguenth
Date: Thu Mar  2 13:42:05 2017
New Revision: 245840

URL: https://gcc.gnu.org/viewcvs?rev=245840&root=gcc&view=rev
2017-03-02  Richard Biener  <rguenther@suse.de>

	PR tree-optimization/79345
	PR c++/42000
	* tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit
	param and abort the walk, returning -1 if it is hit.
	(walk_aliased_vdefs): Take a limit param and pass it on.
	* tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param,
	defaulting to 0 and return a signed int.
	* tree-ssa-uninit.c (struct check_defs_data): New struct.
	(check_defs): New helper.
	(warn_uninitialized_vars): Use walk_aliased_vdefs to warn
	about uninitialized memory.

	* fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid
	bogus uninitialized warning.
	(fixed_convert_from_real): Likewise.

	* g++.dg/warn/Wuninitialized-7.C: New testcase.
	* c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized.
	* gcc.dg/uninit-pr19430-2.c: Add expected warning.