[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning

[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning

[vincent-gcc at vinc17 dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

--- Comment #18 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
This seems to be fixed in the trunk.
>From gcc-bugs-return-435307-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 21 03:12:33 2013
Return-Path: <gcc-bugs-return-435307-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17483 invoked by alias); 21 Nov 2013 03:12:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17433 invoked by uid 48); 21 Nov 2013 03:12:29 -0000
From: "vincent-gcc at vinc17 dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59225] New: missing maybe uninitialized warning following single if
Date: Thu, 21 Nov 2013 03:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: vincent-gcc at vinc17 dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-59225-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg02084.txt.bz2
Content-length: 1009

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY225

            Bug ID: 59225
           Summary: missing maybe uninitialized warning following single
                    if
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincent-gcc at vinc17 dot net

With:
* gcc-4.8 (Debian 4.8.2-5) 4.8.2
* gcc (Debian 20131021-1) 4.9.0 20131021 (experimental) [trunk revision 203899]

xvii:~> cat tst1.c
int foo (int x)
{
  int y;
  if (x == 0)
    y = 1;
  return y;
}

"gcc-snapshot -O2 -Wuninitialized -c tst1.c" doesn't emit any warning.

If I change the code to:

xvii:~> cat tst2.c
int foo (int x)
{
  int y;
  if (x == 0)
    y = 1;
  else if (x == 1)
    y = 2;
  return y;
}

I get the following warning as expected:

tst2.c:8:3: warning: 'y' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   return y;
   ^

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|V_MAY_DEF (taking address   |taking address of a var
                   |of var) causes missing      |causes missing
                   |uninitialized warning       |uninitialized warning
           Severity|minor                       |enhancement

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, fact is we still don't have the machinery that warns for the use of
uninitialized memory - and we never had.  The cases that work by
accident are for loads that alias-analysis can prove we can move to
the function entry (well, a little less than that).

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

--- Comment #25 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #23)
> BTW, I suppose that in this test, -Wuninitialized should be changed to
> "-Wuninitialized -Wmaybe-uninitialized" in case it is decided later that
> -Wuninitialized no longer enables -Wmaybe-uninitialized (see PR59223 about
> that).

I don't see any reason for -Wuninitialized to not enable -Wmaybe-uninitialized.
>From gcc-bugs-return-435439-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 21 18:44:29 2013
Return-Path: <gcc-bugs-return-435439-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7084 invoked by alias); 21 Nov 2013 18:44:29 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6671 invoked by uid 48); 21 Nov 2013 18:44:25 -0000
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59228] ICE with assume type and ASYNCHRONOUS
Date: Thu, 21 Nov 2013 18:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-invalid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: janus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords cc
Message-ID: <bug-59228-4-JBrZZGRvUA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59228-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59228-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg02216.txt.bz2
Content-length: 769

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY228

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
                 CC|                            |janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to Valery Weber from comment #0)
> The following wrong code is producing an ICE with gcc version 4.9.0 20131119.
> Should gcc report an error rank mismatch instead?

It certainly should!


The ICE happens with 4.8 and trunk, while 4.7 rejects the TYPE(*) statement
(together with the rank-mismatch error), so one could regards it as a
regression.

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning

[vincent-gcc at vinc17 dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

--- Comment #26 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Manuel López-Ibáñez from comment #25)
> I don't see any reason for -Wuninitialized to not enable
> -Wmaybe-uninitialized.

I can see 3 kinds of use:

1. Users who are interested in neither: they just don't use these options (if
they want to use -Wall, they need the -Wno- version).

2. Users interested in -Wuninitialized but not in -Wmaybe-uninitialized (to
avoid potential many false positives). Because -Wuninitialized enables
-Wmaybe-uninitialized, they need 2 options: -Wuninitialized
-Wno-maybe-uninitialized. If -Wuninitialized did not enable
-Wmaybe-uninitialized, only one option would be needed: -Wuninitialized.

3. Users interested in both. I think that -Wmaybe-uninitialized should enable
-Wuninitialized because it makes no sense to have -Wmaybe-uninitialized but not
-Wuninitialized. Indeed, if some variable is uninitialized, then it may be
uninitialized. So, only one option should be needed in this case:
-Wmaybe-uninitialized.
>From gcc-bugs-return-435462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 22 00:00:16 2013
Return-Path: <gcc-bugs-return-435462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29705 invoked by alias); 22 Nov 2013 00:00:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29646 invoked by uid 48); 22 Nov 2013 00:00:12 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/58314] SH4 error: 'asm' operand requires impossible reload
Date: Fri, 22 Nov 2013 00:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-58314-4-Mt0uBCaLxB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58314-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58314-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg02239.txt.bz2
Content-length: 4801

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX314

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kkojima at gcc dot gnu.org

--- Comment #9 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to chrbr from comment #5)
> Oleg, I think it time to re-unify those. Doing an experimental resurrection
> of the r,r reload constraints seems to fix it, but without knowing the
> impacts on your T-bit combine optimizations...

OK, I've tried your suggestion by doing ...


Index: gcc/config/sh/sh.md
==================================================================--- gcc/config/sh/sh.md    (revision 205190)
+++ gcc/config/sh/sh.md    (working copy)
@@ -6993,34 +6993,6 @@
   prepare_move_operands (operands, QImode);
 })

-;; If movqi_reg_reg is specified as an alternative of movqi, movqi will be
-;; selected to copy QImode regs.  If one of them happens to be allocated
-;; on the stack, reload will stick to movqi insn and generate wrong
-;; displacement addressing because of the generic m alternatives.
-;; With the movqi_reg_reg being specified before movqi it will be initially
-;; picked to load/store regs.  If the regs regs are on the stack reload
-;; try other insns and not stick to movqi_reg_reg, unless there were spilled
-;; pseudos in which case 'm' constraints pertain.
-;; The same applies to the movhi variants.
-;;
-;; Notice, that T bit is not allowed as a mov src operand here.  This is to
-;; avoid things like (set (reg:QI) (subreg:QI (reg:SI T_REG) 0)), which
-;; introduces zero extensions after T bit stores and redundant reg copies.
-;;
-;; FIXME: We can't use 'arith_reg_operand' (which disallows T_REG) as a
-;; predicate for the mov src operand because reload will have trouble
-;; reloading MAC subregs otherwise.  For that probably special patterns
-;; would be required.
-(define_insn "*mov<mode>_reg_reg"
-  [(set (match_operand:QIHI 0 "arith_reg_dest" "=r,m,*z")
-    (match_operand:QIHI 1 "register_operand" "r,*z,m"))]
-  "TARGET_SH1 && !t_reg_operand (operands[1], VOIDmode)"
-  "@
-    mov    %1,%0
-    mov.<bw>    %1,%0
-    mov.<bw>    %1,%0"
-  [(set_attr "type" "move,store,load")])
-
 ;; FIXME: The non-SH2A and SH2A variants should be combined by adding
 ;; "enabled" attribute as it is done in other targets.
 (define_insn "*mov<mode>_store_mem_disp04"
@@ -7075,33 +7047,35 @@
 ;; displacement addressing modes on anything but SH2A.  That's why the
 ;; specialized load/store insns are specified above.
 (define_insn "*movqi"
-  [(set (match_operand:QI 0 "general_movdst_operand" "=r,r,m,r,l")
-    (match_operand:QI 1 "general_movsrc_operand"  "i,m,r,l,r"))]
+  [(set (match_operand:QI 0 "general_movdst_operand" "=r,r,r,m,r,l")
+    (match_operand:QI 1 "general_movsrc_operand"  "r,i,m,r,l,r"))]
   "TARGET_SH1
    && (arith_reg_operand (operands[0], QImode)
        || arith_reg_operand (operands[1], QImode))"
   "@
     mov    %1,%0
+    mov    %1,%0
     mov.b    %1,%0
     mov.b    %1,%0
     sts    %1,%0
     lds    %1,%0"
- [(set_attr "type" "movi8,load,store,prget,prset")])
+ [(set_attr "type" "move,movi8,load,store,prget,prset")])

 (define_insn "*movhi"
-  [(set (match_operand:HI 0 "general_movdst_operand" "=r,r,r,m,r,l")
-    (match_operand:HI 1 "general_movsrc_operand"  "Q,i,m,r,l,r"))]
+  [(set (match_operand:HI 0 "general_movdst_operand" "=r,r,r,r,m,r,l")
+    (match_operand:HI 1 "general_movsrc_operand"  "r,Q,i,m,r,l,r"))]
   "TARGET_SH1
    && (arith_reg_operand (operands[0], HImode)
        || arith_reg_operand (operands[1], HImode))"
   "@
+    mov    %1,%0
     mov.w    %1,%0
     mov    %1,%0
     mov.w    %1,%0
     mov.w    %1,%0
     sts    %1,%0
     lds    %1,%0"
- [(set_attr "type" "pcload,movi8,load,store,prget,prset")])
+ [(set_attr "type" "move,pcload,movi8,load,store,prget,prset")])

 (define_insn "*movqi_media"
   [(set (match_operand:QI 0 "general_movdst_operand" "=r,r,r,m")


... and it fixes the problem.  The CSiBE set doesn't show any size differences
for SH4, which is a good sign.

make -k check-gcc RUNTESTFLAGS="sh.exp
--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"

also doesn't report new failures.

However, I'm still anxious regarding the comment that reload will generate
wrong displacement addresses because of the generic 'm' alternatives in the
*movqi and *movhi insns.  Maybe the additional reg_reg pattern was a wallpaper
fix after all and is not required anymore.

I'm testing the above patch now.

Kaz, could you please run the above patch through your test setup?  I remember
there were some issues triggered by some fortran code in the test suite...

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #35 from Martin Sebor <msebor at gcc dot gnu.org> ---
GCC 11 issues a warning when the address of an uninitialized variable is passed
to a function that takes a const pointer but it (still) doesn't warn when the
address escapes.  In both cases, it's possible for the called function to store
a value into the variable but because it's highly unlikely issuing a warning
regardless would be appropriate.  In addition, in cases where the address of
the variable doesn't escape until after the function call its value cannot be
affected even when the address is assigned to a non-const pointer.  The escape
analysis is flow insensitive so it alone cannot be relied on to make the
distinction.  But modifying variables this way is rare so issuing the warning
regardless is likely worthwhile.

$ cat a.c && gcc -O2 -S -Wall a.c
extern void f (const void*);

int g (void)
{
  int i;
  f (&i);       // -Wmaybe-uninitialized
  return i;
}

int h (void)
{
  extern const void *p;

  int i;
  f (0);
  p = &i;
  return i;     // missing -Wmaybe-uninitialized
}

a.c: In function ‘int g()’:
a.c:6:5: warning: ‘i’ may be used uninitialized [-Wmaybe-uninitialized]
    6 |   f (&i);
      |   ~~^~~~
a.c:1:13: note: by argument 1 of type ‘const void*’ to ‘void f(const void*)’
declared here
    1 | extern void f (const void*);
      |             ^
a.c:5:7: note: ‘i’ declared here
    5 |   int i;
      |       ^

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |scott.d.phillips at intel dot com

--- Comment #36 from Martin Sebor <msebor at gcc dot gnu.org> ---
*** Bug 78370 has been marked as a duplicate of this bug. ***

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-05-03 18:04:44         |2022-8-29

--- Comment #37 from Richard Biener <rguenth at gcc dot gnu.org> ---
Re-confirmed for the original testcase.  The issue is that while we now try to
perform uninitialized diagnostics for memory we do not perform the maybe-uninit
analysis via PHIs we do for non-memory.  We see

  <bb 2> [local count: 1073741824]:
  # .MEM_5 = VDEF <.MEM_3(D)>
  _1 = bar (i_4(D));
  if (_1 != 0)
    goto <bb 3>; [33.00%]
  else
    goto <bb 5>; [67.00%]

  <bb 5> [local count: 719407024]:
  goto <bb 4>; [100.00%]

  <bb 3> [local count: 354334800]:
  # .MEM_6 = VDEF <.MEM_5>
  baz (&j);

  <bb 4> [local count: 1073741824]:
  # .MEM_2 = PHI <.MEM_5(5), .MEM_6(3)>
  # VUSE <.MEM_2>
  _7 = j;

so when we are walking and looking for defs of 'j' by means of
walk_aliased_vdefs but that will simply process MEM_6 "unordered"
and record that as possible definition.  We are not properly forking
the walk to discover a path where 'j' is not initialized nor are
we trying to compute predicates which guard the use.

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dominiq at lps dot ens.fr

--- Comment #38 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 34721 has been marked as a duplicate of this bug. ***