[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #6 from Martin Sebor --- I didn't write the code but my comments on it and the suggested fix are here: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567626.html
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989
--- Comment #5 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> So perhaps just:
> --- gcc/gimple-ssa-warn-alloca.c.jj 2021-01-04 10:25:38.892233156 +0100
> +++ gcc/gimple-ssa-warn-alloca.c 2021-04-09 12:46:27.466847728 +0200
> @@ -124,9 +124,8 @@ public:
>alloca_type_and_limit (enum alloca_type type,
>wide_int i) : type(type), limit(i) { }
>alloca_type_and_limit (enum alloca_type type) : type(type)
> - { if (type == ALLOCA_BOUND_MAYBE_LARGE
> - || type == ALLOCA_BOUND_DEFINITELY_LARGE)
> - limit = wi::to_wide (integer_zero_node);
> + {
> +limit = wi::to_wide (integer_zero_node);
>}
> };
>
> in this case? Explicitly trying to have limit member conditionally
> uninitialized seems like a bad idea to me.
Yes, that looks good - the existing code is definitely odd, but maybe Martin
can clarify.
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989
--- Comment #4 from Jakub Jelinek ---
So perhaps just:
--- gcc/gimple-ssa-warn-alloca.c.jj 2021-01-04 10:25:38.892233156 +0100
+++ gcc/gimple-ssa-warn-alloca.c2021-04-09 12:46:27.466847728 +0200
@@ -124,9 +124,8 @@ public:
alloca_type_and_limit (enum alloca_type type,
wide_int i) : type(type), limit(i) { }
alloca_type_and_limit (enum alloca_type type) : type(type)
- { if (type == ALLOCA_BOUND_MAYBE_LARGE
- || type == ALLOCA_BOUND_DEFINITELY_LARGE)
- limit = wi::to_wide (integer_zero_node);
+ {
+limit = wi::to_wide (integer_zero_node);
}
};
in this case? Explicitly trying to have limit member conditionally
uninitialized seems like a bad idea to me.
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 --- Comment #3 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > I don't think we want any initialization unless we invent an explicitely > "uninitialized" state. Note that wide-int storage is large - I suppose > initializing precision to zero could be done, but I'd avoid initializing > the storage. FWIW, I agree we shouldn't initialise unless we have a sensible value to initialise to. The problem is that a zero precision has no meaning, but if we initialise to it anyway, it's an extra state that all wide_int accessors have to assert on.
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 --- Comment #2 from Richard Biener --- (In reply to Jakub Jelinek from comment #1) > This isn't the first PR where wide_ints are a problem for -W*uninitialized > warnings. The primary problem is that generic_wide_int default ctor does > nothing and so does wide_int_storage default ctor, so keeps everything > uninitialized. > Do we want some non-default ctor say with some magic enum or whatever > argument that would zero initialize the whole storage? I don't think we want any initialization unless we invent an explicitely "uninitialized" state. Note that wide-int storage is large - I suppose initializing precision to zero could be done, but I'd avoid initializing the storage.
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This isn't the first PR where wide_ints are a problem for -W*uninitialized warnings. The primary problem is that generic_wide_int default ctor does nothing and so does wide_int_storage default ctor, so keeps everything uninitialized. Do we want some non-default ctor say with some magic enum or whatever argument that would zero initialize the whole storage?
[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |11.0
