[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
--- Comment #30 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #29)
> What remains seems to be complaining that
>
> int i;
> foo (&i);
>
> doesn't warn. And we have another bug that
>
> int i;
> foo (&i);
> ... = i;
>
> doesn't warn for the read from i.
>
> I think both of these need a different warning level as foo may not read
> from i and foo may initialize i.
This is not what this bug is about. Please read the discussions. It seems a
waste of people's goodwill and effort over the years to close bugs as
invalid/duplicates without understanding why they were open in the first place.
This bug is about (comment #0)
extern int bar (int);
extern void baz (int *);
int
foo (int i)
{
int j;
if (bar (i)) {
// These should do the same with respect to `j':
baz (&j);
// j = 1;
}
return j;
}
If bar(i) returns false, j is never initialized. The bug implicitly assumes
that baz(&j) does initialize j, thus it satisfies the heuristic used in GCC and
still there should be a "may be" warning.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 --- Comment #32 from Manuel López-Ibáñez --- (In reply to Vincent Lefèvre from comment #31) > In any case, no warnings are generated. So, the problem here is not related > to whether the address of j is taken, but to something else. With a constant, you hit PR18501. If you use "j = i", it warns as it should. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 Manuel López-Ibáñez changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78370 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 Manuel López-Ibáñez changed: What|Removed |Added CC||jimfr06 at gmail dot com --- Comment #34 from Manuel López-Ibáñez --- *** Bug 54544 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 Manuel López-Ibáñez changed: What|Removed |Added Summary|taking address of a var |taking address of a var |causes missing |causes missing |uninitialized warning |uninitialized warning ||(virtual PHI with MEM) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 Manuel López-Ibáñez changed: What|Removed |Added CC||arnd at linaro dot org --- Comment #33 from Manuel López-Ibáñez --- *** Bug 82839 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- Comment #216 from Manuel López-Ibáñez --- (In reply to Vincent Lefèvre from comment #215) > According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status > the possible status are UNCONFIRMED, CONFIRMED and IN_PROGRESS. I think that > the correct one is CONFIRMED. Those are not the main policies. They are here: https://gcc.gnu.org/bugs/management.html fields.html needs to be updated some day to match the actual fields used by GCC (there is no CONFIRMED status, there is NEW) and the above policies. This is one of those bugs that it is so broad, controversial and noisy that almost no active developer is going to look at it. Bugs don't get fixed because they are NEW. There are 6979 NEW bug reports right now and many of them will never get fixed (1300 of them are more than 10 years old). My humble suggestion for those interested in floating-point issues in GCC would be to create self-contained specific bugs with minimised reproducible testcases, a clear analysis of what GCC is doing wrong, what GCC should be doing instead, and suggestions on how it could be fixed. If the bug just says some variation of "optimized code gives strange floating point results", it will end up here and probably nobody will ever look at it. For Rich's specific bug report, the relevant discussion is in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c127 and the expected fix is known: Implement -fexcess-precision=standard for C++ as it was done for C. Perhaps it would be useful to create a new PR that blocks this one that analyses what needs to be done towards that specific goal, collects testcases, etc. The main issue is not that this PR is not in the developers' radar. All GCC developers working on the C/C++ FEs and optimizers are aware of the infamous PR323 and of the solution suggested in comment 127. The issue is simply that no one working on the C++ FE has the time or motivation to implement -fexcess-precision=standard. If you are interested in that, just study this email: https://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html and do for C++ the same steps that Joseph did C. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 Manuel López-Ibáñez changed: What|Removed |Added Assignee|jyasskin at gmail dot com |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW Last reconfirmed|2010-07-13 22:58:26 |2022-8-25 Keywords||patch URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-08/msg00367.htm ||l --- Comment #23 from Manuel López-Ibáñez --- Unassigned so that someone else can take it they wish to. -- You are receiving this mail because: You reported the bug.
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 --- Comment #24 from Manuel López-Ibáñez --- For completeness, this is what LLD says: ld.lld: error: undefined symbol: vtable for A >>> referenced by example.cpp:7 >>> /tmp/example-5d8b98.o:(A::A()) >>> the vtable symbol may be undefined because the class is missing its key >>> function (see https://lld.llvm.org/missingkeyfunction) which seems better. -- You are receiving this mail because: You reported the bug.
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 Manuel López-Ibáñez changed: What|Removed |Added Blocks||46542 --- Comment #9 from Manuel López-Ibáñez 2011-03-17 15:39:00 UTC --- Pending for 4.7 -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-42540-5724-ibh3jpx...@http.gcc.gnu.org/bugzilla/
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302 Manuel López-Ibáñez changed: What|Removed |Added AssignedTo|mueller at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #27 from Manuel López-Ibáñez 2011-06-02 21:43:21 UTC --- Assigned to you Jonathan! Feel free to close it when your patch goes in. If there is something else left to do, it is always better to open a new PR. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-7302-5724-vwoskka...@http.gcc.gnu.org/bugzilla/
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302 --- Comment #28 from Manuel López-Ibáñez 2011-06-02 21:46:13 UTC --- (In reply to comment #26) > I've posted a patch to http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00191.html > which gives this for the code in comment 25 BTW, I would suggest that you use warning_at, but I guess this is a lost battle. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-7302-5724-dzoo7ny...@http.gcc.gnu.org/bugzilla/
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #195 from Manuel López-Ibáñez --- (In reply to Martin von Gagern from comment #193) > Would it make sense to file one bug report per language, marking all of them > as blocking this one here, so we can keep track of progress per language? > I'm particularly interested in C++, but I guess others might care for other > front-ends. Feel free to do just that, specially if you are planning to work on it. This PR has become too long and full of outdated info (and useless comments) to be really useful. -- You are receiving this mail because: You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/bug-323-5724-dvb6z6d...@http.gcc.gnu.org/bugzilla/
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Manuel López-Ibáñez changed: What|Removed |Added URL||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=323#c127 --- Comment #196 from Manuel López-Ibáñez --- I believe the latest status of this PR is explained by comment 127. I added this as the URL of the bug for people to find. Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general) is seriously lacking info and outdated. From now on, I'll point people to: https://gcc.gnu.org/wiki/FAQ#PR323 -- You are receiving this mail because: You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/bug-323-5724-09rraoa...@http.gcc.gnu.org/bugzilla/
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- Comment #198 from Manuel López-Ibáñez --- (In reply to Vincent Lefèvre from comment #197) > (In reply to Manuel López-Ibáñez from comment #196) > > Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general) > > is seriously lacking info and outdated. From now on, I'll point people to: > > https://gcc.gnu.org/wiki/FAQ#PR323 > > Note that this bug was mainly about the excess precision of x87 FPU, though I added your comment to the FAQ but feel welcome to extend it: https://gcc.gnu.org/wiki/FAQ#PR323 What it is also missing is a criteria to distinguish normal behavior from actual GCC bugs (and there are GCC bugs like bug 37845 and others for optimizations that should only be done with ffast-math). Currently, any floating-point issue is likely to end up here. -- You are receiving this mail because: You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/bug-323-5724-wzxkef7...@http.gcc.gnu.org/bugzilla/
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 Manuel López-Ibáñez changed: What|Removed |Added CC||tisaac at ices dot utexas.edu --- Comment #28 from Manuel López-Ibáñez --- *** Bug 65182 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/bug-19430-5724-azte3du...@http.gcc.gnu.org/bugzilla/
[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 --- Comment #19 from Manuel López-Ibáñez --- (In reply to Vincent Lefèvre from comment #18) > This seems to be fixed in the trunk. Is there an XPASS for gcc.dg/uninit-pr19430.c ? Also, the testcase from bug 42079? -- You are receiving this mail because: You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-19430-5724-uli8chh...@http.gcc.gnu.org/bugzilla/
[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
--- Comment #20 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #19)
> (In reply to Vincent Lefèvre from comment #18)
> > This seems to be fixed in the trunk.
>
> Is there an XPASS for gcc.dg/uninit-pr19430.c ?
>
> Also, the testcase from bug 42079?
Clang warns for this in the FE without any optimization:
gcc.dg/uninit-pr19430.c:10:7: warning: variable 'j' is used uninitialized
whenever 'if' condition is false [-Wsometimes-uninitialized]
if (bar (i)) {
^~~
gcc.dg/uninit-pr19430.c:15:10: note: uninitialized use occurs here
return j;
^
gcc.dg/uninit-pr19430.c:10:3: note: remove the 'if' if its condition is always
true
if (bar (i)) {
^
gcc.dg/uninit-pr19430.c:8:8: note: initialize the variable 'j' to silence this
warning
int j; /* { dg-warning "'j' may be used uninitialized in this function"
"uninitialized" { xfail *-*-* } 8 } */
^
= 0
--
You are receiving this mail because:
You are on the CC list for the bug.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/bug-19430-5724-ouxsgi6...@http.gcc.gnu.org/bugzilla/
[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
--- Comment #21 from Manuel López-Ibáñez ---
$ ~/test1/205036M/build/gcc/cc1 -O1 -Wuninitialized test.c
-fdump-tree-all-all-lineno
$ cat test.c.139t.uninit1
foo (intD.6 iD.1789)
{
intD.6 jD.1792;
intD.6 _5;
intD.6 _7;
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 5, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
;; starting at line 10
[test.c : 10:11] # .MEM_4 = VDEF <.MEM_2(D)>
# USE = nonlocal { D.1792 } (escaped)
# CLB = nonlocal { D.1792 } (escaped)
_5 = barD.1786 (i_3(D));
[test.c : 10:6] if (_5 != 0)
goto ;
else
goto ;
;;succ: 3 [39.0%] (TRUE_VALUE,EXECUTABLE)
;;5 [61.0%] (FALSE_VALUE,EXECUTABLE)
;; basic block 5, loop depth 0, count 0, freq 6102, maybe hot
;;prev block 2, next block 3, flags: (NEW)
;;pred: 2 [61.0%] (FALSE_VALUE,EXECUTABLE)
;;
goto ;
;;succ: 4 [100.0%] (FALLTHRU)
;; basic block 3, loop depth 0, count 0, freq 3898, maybe hot
;;prev block 5, next block 4, flags: (NEW, REACHABLE)
;;pred: 2 [39.0%] (TRUE_VALUE,EXECUTABLE)
;; starting at line 11
[test.c : 11:9] # .MEM_6 = VDEF <.MEM_4>
# USE = nonlocal { D.1792 } (escaped)
# CLB = nonlocal { D.1792 } (escaped)
bazD.1788 ([test.c : 11] &jD.1792);
;;succ: 4 [100.0%] (FALLTHRU,EXECUTABLE)
;; basic block 4, loop depth 0, count 0, freq 1, maybe hot
;;prev block 3, next block 1, flags: (NEW, REACHABLE)
;;pred: 5 [100.0%] (FALLTHRU)
;;3 [100.0%] (FALLTHRU,EXECUTABLE)
;; starting at line 14
# .MEM_1 = PHI <.MEM_4(5), .MEM_6(3)>
[test.c : 14:3] # VUSE <.MEM_1>
_7 = jD.1792;
# .MEM_8 = VDEF <.MEM_1>
jD.1792 ={v} {CLOBBER};
[test.c : 14:3] # VUSE <.MEM_8>
return _7;
;;succ: EXIT [100.0%]
}
It seems one could follow every operand of the MEM_1 PHI node until you find
the MEM_4 = VDEF <.MEM_2(D)>. But perhaps this may produce a lot of false
positives.
The uninit pass avoids virtual operands on purpose, so it cannot be that
trivial.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/bug-19430-5724-cesvi55...@http.gcc.gnu.org/bugzilla/
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 --- Comment #25 from Manuel López-Ibáñez --- (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. -- You are receiving this mail because: You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-19430-5724-rcrfw3r...@http.gcc.gnu.org/bugzilla/
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 --- Comment #27 from Manuel López-Ibáñez --- (In reply to Vincent Lefèvre from comment #26) > (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). -Wall -Wno-uninitialized suppresses both. > 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. This argument goes both ways: if you are interested in both warnings, you would need both options. > 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. Aha! This is a really good point on which I can agree. However, it will seriously break backwards compatibility for people that use either -Wuninitialized or -Wno-uninitialized explicitly. I am not sure if the pain is worth the beauty. I don't think it is worth to discuss this in Bugzilla (specially not on this PR). If you are convinced that this is the right thing to do, you could propose a patch to gcc-patches and see how people receive it. -- You are receiving this mail because: You are on the CC list for the bug. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bug-19430-5724-vp8eqih...@http.gcc.gnu.org/bugzilla/
