[Bug middle-end/70069] Uninitialized value default to zero, plus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 87210 *** This bug has been marked as a duplicate of bug 87210 ***
[Bug middle-end/70069] Uninitialized value default to zero, plus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069 Martin Sebor changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #4 from Martin Sebor --- *** Bug 99797 has been marked as a duplicate of this bug. ***
[Bug middle-end/70069] Uninitialized value default to zero, plus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069 Martin Sebor changed: What|Removed |Added Blocks||24639 CC||msebor at gcc dot gnu.org Keywords||patch --- Comment #3 from Martin Sebor --- A POC patch along these lines was submitted here: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565514.html Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug middle-end/70069] Uninitialized value default to zero, plus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-04 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Funnily we have already the init-regs pass on RTL that does some of this zero-initialization (for registers only though), but it's quite late. >From an implementation perspective the easiest place to add the extra zero inits is when we still have BIND exprs around (you'd want to restrict zero-init to user variables and do it when variables go into scope). Probably at the same place where we add CLOBBERs to mark EOL of locals, thus gimplification. Btw, if you add the possibility to zero-init then maybe also allow different init patterns (it would be 'memset'-like to cover arbitrary types). -finit-vars[=value] where 'value' is either a byte value so we can use memset directly or a larger value that is appropriately memcpy'ed as if it were repeated. Note that if you do this at -O0 you'll for sure get larger code as nothing will optimize away the redundant zero-inits. Note that these zero-inits might trick other passes into doing different optimizations than if they were not present (and not only due to removed undefinedness) - consider the inliners (or other passes) size estimates for example or SRAs heuristics on present reads/writes to decide on what transforms to apply.
[Bug middle-end/70069] Uninitialized value default to zero, plus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- This is one of the ideas discussed here: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#Problem_1:_CCP_assumes_a_value_for_uninitialized_variables and here: PR18501 The problem is that: 1) Either the default-initialization (but then it cannot be simply zero initialization as proposed by Ingo) is treated as UNDEFINED for purposes of optimization, which means we still will miss warnings such as PR18501 and still return random stuff depending on optimization. We may be able to warn for a few more cases of uninitialized (different from other causes of undefinedness?), but I think not many if any at all. 2) Or the default-initialization is treated as non-UNDEFINED value (then it can be zero, but how to distinguish a real zero from a "fake" zero?), which will prevent optimizations in cases where the compiler cannot use the undefinedness to simplify code (I don't know how much we gain/lose by this, but it is definitely used by CPP/VRP. Someone would need to add some counters and compile some critical pieces of software, do benchmarking, etc.). 3) Or we have some dirty/undef bit which is properly propagated everytime we fold/simplify/CPP/VRP using an undef value. But this seems quite a lot of work. We have trouble to track overflow properly. This seems at least as hard, probably more since it applies to any type. It will also increase the number of false-positives (when GCC cannot remove the value with the dirty bit, but the value or the path that caused the bit to be set are never executed). Note that the above will only fix one of the major problems listed in the wiki page (admittedly the major false-negative problem). Other issues listed there would require different fixes. (I'm tempted to mark this as a duplicate of PR18501, since it is where the conversation should be, but you can do that if you think it is appropriate). Of course, anyone is welcome to try any of the above options and see what happens! Even if they fail, we would at least understand better the problem. I wish kernel hackers stopped saying GCC devs must be stupid and actually proved us stupid by getting their patch committed and working for a whole release and dealing with all the backlash from users if they got some details wrong (too little/too much/different optimization or warnings). Just see how much fine-tuning David has done to Wmisleading-indentation, and that seems trivial (it is not trivial at all!) compared to this.
