[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

["rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.