https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
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.
