public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning [not found] <bug-19430-4@http.gcc.gnu.org/bugzilla/> @ 2013-11-21 3:11 ` vincent-gcc at vinc17 dot net 2013-11-21 12:16 ` [Bug middle-end/19430] taking address of a var " rguenth at gcc dot gnu.org ` (6 subsequent siblings) 7 siblings, 0 replies; 12+ messages in thread From: vincent-gcc at vinc17 dot net @ 2013-11-21 3:11 UTC (permalink / raw) To: gcc-bugs 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; ^ ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug middle-end/19430] taking address of a var causes missing uninitialized warning [not found] <bug-19430-4@http.gcc.gnu.org/bugzilla/> 2013-11-21 3:11 ` [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning vincent-gcc at vinc17 dot net @ 2013-11-21 12:16 ` rguenth at gcc dot gnu.org 2013-11-21 18:31 ` manu at gcc dot gnu.org ` (5 subsequent siblings) 7 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2013-11-21 12:16 UTC (permalink / raw) To: gcc-bugs 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). ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug middle-end/19430] taking address of a var causes missing uninitialized warning [not found] <bug-19430-4@http.gcc.gnu.org/bugzilla/> 2013-11-21 3:11 ` [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning vincent-gcc at vinc17 dot net 2013-11-21 12:16 ` [Bug middle-end/19430] taking address of a var " rguenth at gcc dot gnu.org @ 2013-11-21 18:31 ` manu at gcc dot gnu.org 2013-11-21 23:57 ` vincent-gcc at vinc17 dot net ` (4 subsequent siblings) 7 siblings, 0 replies; 12+ messages in thread From: manu at gcc dot gnu.org @ 2013-11-21 18:31 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug middle-end/19430] taking address of a var causes missing uninitialized warning [not found] <bug-19430-4@http.gcc.gnu.org/bugzilla/> ` (2 preceding siblings ...) 2013-11-21 18:31 ` manu at gcc dot gnu.org @ 2013-11-21 23:57 ` vincent-gcc at vinc17 dot net 2020-10-27 17:05 ` [Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM) msebor at gcc dot gnu.org ` (3 subsequent siblings) 7 siblings, 0 replies; 12+ messages in thread From: vincent-gcc at vinc17 dot net @ 2013-11-21 23:57 UTC (permalink / raw) To: gcc-bugs 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... ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM) [not found] <bug-19430-4@http.gcc.gnu.org/bugzilla/> ` (3 preceding siblings ...) 2013-11-21 23:57 ` vincent-gcc at vinc17 dot net @ 2020-10-27 17:05 ` msebor at gcc dot gnu.org 2021-04-01 0:23 ` msebor at gcc dot gnu.org ` (2 subsequent siblings) 7 siblings, 0 replies; 12+ messages in thread From: msebor at gcc dot gnu.org @ 2020-10-27 17:05 UTC (permalink / raw) To: gcc-bugs 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; | ^ ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM) [not found] <bug-19430-4@http.gcc.gnu.org/bugzilla/> ` (4 preceding siblings ...) 2020-10-27 17:05 ` [Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM) msebor at gcc dot gnu.org @ 2021-04-01 0:23 ` msebor at gcc dot gnu.org 2022-08-29 13:08 ` rguenth at gcc dot gnu.org 2022-08-29 13:16 ` rguenth at gcc dot gnu.org 7 siblings, 0 replies; 12+ messages in thread From: msebor at gcc dot gnu.org @ 2021-04-01 0:23 UTC (permalink / raw) To: gcc-bugs 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. *** ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM) [not found] <bug-19430-4@http.gcc.gnu.org/bugzilla/> ` (5 preceding siblings ...) 2021-04-01 0:23 ` msebor at gcc dot gnu.org @ 2022-08-29 13:08 ` rguenth at gcc dot gnu.org 2022-08-29 13:16 ` rguenth at gcc dot gnu.org 7 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2022-08-29 13:08 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM) [not found] <bug-19430-4@http.gcc.gnu.org/bugzilla/> ` (6 preceding siblings ...) 2022-08-29 13:08 ` rguenth at gcc dot gnu.org @ 2022-08-29 13:16 ` rguenth at gcc dot gnu.org 7 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2022-08-29 13:16 UTC (permalink / raw) To: gcc-bugs 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. *** ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <bug-19430-9033@http.gcc.gnu.org/bugzilla/>]
* [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning [not found] <bug-19430-9033@http.gcc.gnu.org/bugzilla/> @ 2007-08-15 15:36 ` manu at gcc dot gnu dot org 2007-08-17 9:17 ` manu at gcc dot gnu dot org ` (2 subsequent siblings) 3 siblings, 0 replies; 12+ messages in thread From: manu at gcc dot gnu dot org @ 2007-08-15 15:36 UTC (permalink / raw) To: gcc-bugs ------- Comment #14 from manu at gcc dot gnu dot org 2007-08-15 15:36 ------- Trying to improve the summary to help spot duplicates. -- manu at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manu at gcc dot gnu dot org Summary|Missing uninitialized |V_MAY_DEF (taking address of |warning |var) causes missing | |uninitialized warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning [not found] <bug-19430-9033@http.gcc.gnu.org/bugzilla/> 2007-08-15 15:36 ` [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning manu at gcc dot gnu dot org @ 2007-08-17 9:17 ` manu at gcc dot gnu dot org 2008-08-20 22:32 ` manu at gcc dot gnu dot org 2009-11-19 12:01 ` manu at gcc dot gnu dot org 3 siblings, 0 replies; 12+ messages in thread From: manu at gcc dot gnu dot org @ 2007-08-17 9:17 UTC (permalink / raw) To: gcc-bugs ------- Comment #15 from manu at gcc dot gnu dot org 2007-08-17 09:17 ------- This seems to me a duplicate of PR179. I am going to add a dependency to remember to check this PR when PR179 gets fixed. -- manu at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |179 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning [not found] <bug-19430-9033@http.gcc.gnu.org/bugzilla/> 2007-08-15 15:36 ` [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning manu at gcc dot gnu dot org 2007-08-17 9:17 ` manu at gcc dot gnu dot org @ 2008-08-20 22:32 ` manu at gcc dot gnu dot org 2009-11-19 12:01 ` manu at gcc dot gnu dot org 3 siblings, 0 replies; 12+ messages in thread From: manu at gcc dot gnu dot org @ 2008-08-20 22:32 UTC (permalink / raw) To: gcc-bugs ------- Comment #16 from manu at gcc dot gnu dot org 2008-08-20 22:31 ------- All testcases except the one in the original description were actually duplicates of PR179 and are thusly fixed. The original testcase deals with PHI ops which is a completely different beast. I added it XFAILED as gcc.dg/uninit-pr19430.c but I doubt it will get magically fixed, so suggestions/patches welcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning [not found] <bug-19430-9033@http.gcc.gnu.org/bugzilla/> ` (2 preceding siblings ...) 2008-08-20 22:32 ` manu at gcc dot gnu dot org @ 2009-11-19 12:01 ` manu at gcc dot gnu dot org 3 siblings, 0 replies; 12+ messages in thread From: manu at gcc dot gnu dot org @ 2009-11-19 12:01 UTC (permalink / raw) To: gcc-bugs ------- Comment #17 from manu at gcc dot gnu dot org 2009-11-19 12:00 ------- *** Bug 42079 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m dot b dot lankhorst at | |gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-08-29 13:16 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bug-19430-4@http.gcc.gnu.org/bugzilla/> 2013-11-21 3:11 ` [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning vincent-gcc at vinc17 dot net 2013-11-21 12:16 ` [Bug middle-end/19430] taking address of a var " rguenth at gcc dot gnu.org 2013-11-21 18:31 ` manu at gcc dot gnu.org 2013-11-21 23:57 ` vincent-gcc at vinc17 dot net 2020-10-27 17:05 ` [Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM) msebor at gcc dot gnu.org 2021-04-01 0:23 ` msebor at gcc dot gnu.org 2022-08-29 13:08 ` rguenth at gcc dot gnu.org 2022-08-29 13:16 ` rguenth at gcc dot gnu.org [not found] <bug-19430-9033@http.gcc.gnu.org/bugzilla/> 2007-08-15 15:36 ` [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning manu at gcc dot gnu dot org 2007-08-17 9:17 ` manu at gcc dot gnu dot org 2008-08-20 22:32 ` manu at gcc dot gnu dot org 2009-11-19 12:01 ` manu at gcc dot gnu dot org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).