Bug 69537

Summary: [6 Regression] Incorrect -Wmaybe-uninitialized warning with enum variable
Product: gcc Reporter: Florian Weimer <fw>
Component: middle-endAssignee: Richard Biener <rguenth>
Status: RESOLVED FIXED    
Severity: normal CC: jakub
Priority: P3    
Version: 6.0   
Target Milestone: 6.0   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2016-01-28 00:00:00
Bug Depends on: 69586    
Bug Blocks:    

Description Florian Weimer 2016-01-28 13:18:57 UTC 
gcc -O2 -Wall yields:

t.c: In function ‘yp_update’:
t.c:27:3: warning: ‘master’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   __builtin_free (master); // -Wmaybe-uninitialized warning here
   ^~~~~~~~~~~~~~~~~~~~~~~

According to Jakub Jelinek, this started with r225861.


enum clnt_stat {
 RPC_SUCCESS=0,
 RPC_CANTENCODEARGS=1,
};
 
int do_ypcall_tr ();
 
static int
yp_master (char **outname)
{
  // Replacing enum clnt_stat with int avoids the warning.
  enum clnt_stat result;
  result = do_ypcall_tr ();
  if (result != 0)
    return result;
  *outname = __builtin_strdup ("foo");
  return 0;
}
 
int
yp_update (void)
{
  char *master;
  int r;
  if ((r = yp_master (&master)) != 0)
    return r;
  __builtin_free (master); // -Wmaybe-uninitialized warning here
  return 0;
}
Comment 1 Jakub Jelinek 2016-01-28 13:33:26 UTC 
r225860 vs. r225861 differences start at forwprop1:
-  if (_5 != 0)
+  result_6 = (clnt_stat) _5;
+  if (result_6 != 0)
and after a while, with r225861+ we even have more bbs than previously, and only RTL optimizations fix that up, so we get identical assembly.
Comment 2 Richard Biener 2016-01-28 13:40:10 UTC 
I will have a look.
Comment 3 Richard Biener 2016-01-28 13:55:30 UTC 
Ok, so this is the check copied from fold-const.c:

  (if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE

and thus we reject the ENUM_TYPE here:

  if (TREE_CODE (TREE_TYPE (arg0)) == INTEGER_TYPE
      && CONVERT_EXPR_P (arg0))
    {
      /* If we are widening one operand of an integer comparison,
         see if the other operand is similarly being widened.  Perhaps we
         can do the comparison in the narrower type.  */
      tem = fold_widened_comparison (loc, code, type, arg0, arg1);
      if (tem)
        return tem;

      /* Or if we are changing signedness.  */
      tem = fold_sign_changed_comparison (loc, code, type, arg0, arg1);
      if (tem)
        return tem;
    }

not sure how this was optimized before.  Note that we happily accepted
non-INTEGER_TYPE operand of the conversion.

When moving the code I didn't want to change the predicate to INTEGRAL_TYPE_P
but I guess this is what I am going to test now (without trying to track
down how exactly we got to bypass that back in time...).
Comment 4 Jakub Jelinek 2016-01-28 14:01:00 UTC 
Yeah, in the match.pd hunk there is quite a lot of == INTEGER_TYPE.  I bet ENUMERAL_TYPE can be always handled the same, the question is about BOOLEAN_TYPE.
Comment 5 rguenther@suse.de 2016-01-28 14:04:06 UTC 
On Thu, 28 Jan 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69537
> 
> --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Yeah, in the match.pd hunk there is quite a lot of == INTEGER_TYPE.  I bet
> ENUMERAL_TYPE can be always handled the same, the question is about
> BOOLEAN_TYPE.

I refrained from editing the patterns I moved from fold-const.c at
the same time as I moved them just to avoid introducing new bugs.

You might confuse == INTEGER_CST with == INTEGER_TYPE though as
there is only one place with == INTEGER_TYPE in whole match.pd.
Comment 6 Richard Biener 2016-01-29 08:36:12 UTC 
Fixed.
Comment 7 Richard Biener 2016-01-29 08:36:36 UTC 
Author: rguenth
Date: Fri Jan 29 08:36:04 2016
New Revision: 232968

URL: https://gcc.gnu.org/viewcvs?rev=232968&root=gcc&view=rev
Log:
2016-01-29  Richard Biener  <rguenther@suse.de>

	PR middle-end/69537
	* match.pd: Allow all integral types when simplifying a
	widening or sign-changing conversion.

	* gcc.dg/uninit-21.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/uninit-21.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/match.pd
    trunk/gcc/testsuite/ChangeLog
Comment 8 ian@gcc.gnu.org 2016-02-09 00:35:27 UTC 
Author: ian
Date: Tue Feb  9 00:34:55 2016
New Revision: 233235

URL: https://gcc.gnu.org/viewcvs?rev=233235&root=gcc&view=rev
Log:
	PR go/69537
    runtime: Don't refer to _end symbol in shared library.
    
    Fixes GCC PR 69357.
    
    Reviewed-on: https://go-review.googlesource.com/19362

Modified:
    trunk/gcc/go/gofrontend/MERGE
    trunk/libgo/runtime/go-main.c
    trunk/libgo/runtime/malloc.goc
    trunk/libgo/runtime/runtime.h