https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #5 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
(In reply to Martin Sebor from comment #3)
> Simply initializing the variable as in the patch below avoids the warning.
> The control flow in the code is sufficiently opaque to make it worthwhile
> from a readability point irrespective of whether or not the variable can, in
> fact, be used uninitialized.
>
> index e50d3fc3b62..c7f0a405ff6 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -199,7 +199,7 @@ stack_region_maybe_used_p (poly_uint64 lower_bound,
> poly_uint64 upper_bound,
> static void
> mark_stack_region_used (poly_uint64 lower_bound, poly_uint64 upper_bound)
> {
> - unsigned HOST_WIDE_INT const_lower, const_upper;
> + unsigned HOST_WIDE_INT const_lower, const_upper = 0;
> const_lower = constant_lower_bound (lower_bound);
> if (upper_bound.is_constant (&const_upper))
> for (unsigned HOST_WIDE_INT i = const_lower; i < const_upper; ++i)
I disagree that this is better for readability. Initialising to zero
implies that the zero can reach code dominated by is_constant returning
true. In other words, it implies that the zero might be used and that
initialising to a different value would give different behaviour,
which in turn raises the question why 0 is the right choice.
The control flow for is_constant is just:
if (is_constant ())
{
*const_value = this->coeffs[0];
return true;
}
return false;
where it is clear that const_value is assigned to iff the
function returns true. If we can't handle this kind of
construct then I think we should try to punt on it.
It doesn't seem all that different from what would happen
for std::optional<std::array<int, 2>> after SRA, where AIUI
the second array element would be uninitialised if
_M_engaged is false.
