User account creation filtered due to spam.

Bug 41952

Summary: patch to improve Wuninitialized
Product: gcc Reporter: davidxl <xinliangli>
Component: middle-endAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: enhancement CC: gcc-bugs, manu
Priority: P3 Keywords: diagnostic, missed-optimization, patch
Version: 4.4.3   
Target Milestone: 4.6.0   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2009-11-06 10:01:05
Bug Depends on:    
Bug Blocks: 24639, 41998    
Attachments: proposed patch

Description davidxl 2009-11-05 18:17:01 UTC
Compiling the following example with -Wuninitialized, 4.4 gcc will emit false warning on uninitialized variable. In fact the definition is guarded by a condition which is always true (coming from the assignment operator) for locals. The solution is to fold the predicate (see proposed patch).

On 4.5, due to vsym related changes, the false positive warning issue is masked (but false negative one occurs -- see a different PR). While this patch can be used to fix the 4.4 issue, it is also applicable to 4.5 as a very safe optimization. Is it ok to get it in at this stage?


#ifndef WORK_AROUND_GCC_4_4_0_BROKENNESS
#define WORK_AROUND_GCC_4_4_0_BROKENNESS 0
#endif

struct ExtentsBase {
 ExtentsBase() : startx_(), endx_() { }
 ExtentsBase(const ExtentsBase &b) {
  *this = b;
 }

 const ExtentsBase & operator=(const ExtentsBase &b) {
  if (this != &b || WORK_AROUND_GCC_4_4_0_BROKENNESS) {
    startx_ = b.startx_;
  }
  return *this;
 }

 int startx_;
  int endx_;
};

int f(const ExtentsBase &e1) {
 ExtentsBase my_extents = e1;
 return my_extents.startx_;
}

====================

self2.cc: In function 'int f(const ExtentsBase&)':
self2.cc:25: warning: 'my_extents' may be used uninitialized in this function
Comment 1 davidxl 2009-11-05 18:18:56 UTC
Created attachment 18975 [details]
proposed patch

Bootstrapped and regression tested on x86-64 linux with gcc 4.5
Comment 2 Richard Biener 2009-11-06 10:01:05 UTC
Patches should go to gcc-patches, you need to add the testcase and you
should use auto_var_in_fn_p instead of !is_global_var.
Comment 3 davidxl 2009-11-06 18:11:51 UTC
(In reply to comment #2)
> Patches should go to gcc-patches, you need to add the testcase and you
> should use auto_var_in_fn_p instead of !is_global_var.
> 

auto_var_in_fn_p uses DECL_CONTEXT --- is it guaranteed to always point to the enclosing functions even for inner block scoped locals (it seems so now).


David
Comment 4 Richard Biener 2009-11-06 19:06:11 UTC
Yes, the predicate is implemented correctly.
Comment 5 H.J. Lu 2010-04-29 20:40:19 UTC
Fixed by revision 158567:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00673.html