[Bug middle-end/99989] New: [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64

[Bug middle-end/99989] New: [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

            Bug ID: 99989
           Summary: [11 regression] False maybe-uninitialized warning
                    breaks bootstrap on riscv64
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: schwab@linux-m68k.org
                CC: hubicka at gcc dot gnu.org
            Blocks: 24639, 98265
  Target Milestone: ---
            Target: riscv64-*-*

In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool
’,
    inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret +
offsetof(alloca_type_and_limit,
alloca_type_and_limit::limit.generic_wide_int<wide_int_storage>::<unnamed>.wide_int_storage::val[0]))’
may be used uninitialized  -Werror=maybe-uninitialized]
  206 |         ret = alloca_type_and_limit (ALLOCA_OK);
      |         ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
  200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
      |                                ^~~
In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool
’,
    inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret +
offsetof(alloca_type_and_limit,
alloca_type_and_limit::limit.generic_wide_int<wide_int_storage>::<unnamed>.wide_int_storage::val[1]))’
may be used uninitialized  -Werror=maybe-uninitialized]
  206 |         ret = alloca_type_and_limit (ALLOCA_OK);
      |         ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
  200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
      |                                ^~~
In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool
’,
    inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret +
offsetof(alloca_type_and_limit,
alloca_type_and_limit::limit.generic_wide_int<wide_int_storage>::<unnamed>.wide_int_storage::val[2]))’
may be used uninitialized  -Werror=maybe-uninitialized]
  206 |         ret = alloca_type_and_limit (ALLOCA_OK);
      |         ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
  200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
      |                                ^~~
In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool
’,
    inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(unsigned int*)((char*)&ret
+ offsetof(alloca_type_and_limit,
alloca_type_and_limit::limit.generic_wide_int<wide_int_storage>::<unnamed>.wide_int_storage::len))’
may be used uninitialized [-Werror=maybe-uninitialized]
  206 |         ret = alloca_type_and_limit (ALLOCA_OK);
      |         ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
  200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
      |                                ^~~
In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool
’,
    inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(unsigned int*)((char*)&ret
+ offsetof(alloca_type_and_limit,
alloca_type_and_limit::limit.generic_wide_int<wide_int_storage>::<unnamed>.wide_int_storage::precision))’
may be used uninitialized [-Werror=maybe-uninitialized]
  206 |         ret = alloca_type_and_limit (ALLOCA_OK);
      |         ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
  200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
      |                                ^~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1142: gimple-ssa-warn-alloca.o] Error 1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265
[Bug 98265] [10/11 Regression] gcc-10 has significantly worse code generated
with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library

[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0

[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

--- Comment #3 from rsandifo at gcc dot gnu.org <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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.

[Bug middle-end/99989] [11 regression] False maybe-uninitialized warning breaks bootstrap on riscv64

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
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] -Wmaybe-uninitialized warning breaks bootstrap on riscv64

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11 regression] False       |[11 regression]
                   |maybe-uninitialized warning |-Wmaybe-uninitialized
                   |breaks bootstrap on riscv64 |warning breaks bootstrap on
                   |                            |riscv64

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning is a true positive caused by assigning a struct with an
uninitialized member.  Adjusting Summary.

[Bug middle-end/99989] [11 regression] -Wmaybe-uninitialized warning breaks bootstrap on riscv64

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:3e350d8539a4e28ddc30d0f08a4040f10b699135

commit r11-8107-g3e350d8539a4e28ddc30d0f08a4040f10b699135
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Apr 10 12:48:04 2021 +0200

    gimple-ssa-warn-alloca: Always initialize limit [PR99989]

    This PR is about a -W*uninitialized warning on riscv64.
    alloca_type_and_limit is documented to have limit member only defined
    when type is ALLOCA_BOUND_MAYBE_LARGE or ALLOCA_BOUND_DEFINITELY_LARGE
    and otherwise just default constructs limit, which for wide_int means
    no initialization at all.  IMHO it is fine not to use the limit
    member otherwise, but trying to not initialize it when it can be e.g.
    copied around and then invoke UB doesn't look like a good idea.

    2021-04-10  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99989
            * gimple-ssa-warn-alloca.c
            (alloca_type_and_limit::alloca_type_and_limit): Initialize limit to
            0 with integer precision unconditionally.

[Bug middle-end/99989] [11 regression] -Wmaybe-uninitialized warning breaks bootstrap on riscv64

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can't verify it the above commit fixes it though, so keeping the PR open until
somebody confirms it (or attaches preprocessed source so that I could verify
with cross-compiler).

[Bug middle-end/99989] [11 regression] -Wmaybe-uninitialized warning breaks bootstrap on riscv64

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #10 from Andreas Schwab <schwab@linux-m68k.org> ---
Verified.