[Bug fortran/66459] New: bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]

[Bug fortran/66459] New: bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]

[mario-baumann at web dot de]

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

            Bug ID: 66459
           Summary: bogus warning 'w.offset' may be used uninitialized in
                    this function [-Wmaybe-uninitialized]
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mario-baumann at web dot de
  Target Milestone: ---

Created attachment 35716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35716&action=edit
Fortran Fixed Form File

Hi All,

The attached file generates bogus warnings if compiled with -Wall AND -O1(or
higher optimizations).


> gfortran -c -Wall -O1 foo.F
foo.F:14:0:

                W(J,I) = 0
 ^
Warning: 'w.offset' may be used uninitialized in this function
[-Wmaybe-uninitialized]
foo.F:14:0: Warning: 'w.dim[1].stride' may be used uninitialized in this
function [-Wmaybe-uninitialized]


> gfortran -v
Using built-in specs.
COLLECT_GCC=./gfortran
COLLECT_LTO_WRAPPER=/Build/gcc/5.1.0/install/libexec/gcc/x86_64-apple-darwin13/5.1.0/lto-wrapper
Target: x86_64-apple-darwin13
Configured with: /Source/gcc/5.1.0/configure --prefix=/Build/gcc/5.1.0/install
--build=x86_64-apple-darwin13 --enable-languages=c,c++,fortran,lto
--enable-cloog-backend=isl --enable-stage1-checking --enable-lto
--enable-libstdcxx-time --with-system-zlib --disable-cloog-version-check
--disable-nls --disable-libquadmath-support
Thread model: posix
gcc version 5.1.0 (GCC)


NOTEs:
- -O0 works fine
- same behaviour with gcc-4.9.2

[Bug fortran/66459] bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-08
                 CC|                            |mikael at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Mikael Morin <mikael at gcc dot gnu.org> ---
Confirmed.
Possibly related bug: PR60500

(In reply to Mario Baumann from comment #0)
> - -O0 works fine

This is expected, uninitializedness may only become apparent to the compiler
after some optimization passes have simplified/reorganized the code.

[Bug tree-optimization/66459] bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized] caused by loop invariant motion (LIM)

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2019-02-03 00:00:00         |2022-8-30
            Summary|bogus warning 'w.offset'    |bogus warning 'w.offset'
                   |may be used uninitialized   |may be used uninitialized
                   |in this function            |in this function
                   |[-Wmaybe-uninitialized]     |[-Wmaybe-uninitialized]
                   |                            |caused by loop invariant
                   |                            |motion (LIM)

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
what we warn about in the end is the path when l == 0 && n > 0.  that's also
visible in the initial gfortran IL:

  try
    {
      w.data = 0B;
      w.dtype = {.elem_len=4, .rank=2, .type=1};
      if (*l)
        {
...
        }
      L.1:;
      {
        integer(kind=4) D.4258;

        D.4258 = *n;
        i = 1;
        while (1)
          {
            {
              logical(kind=4) D.4261;

              D.4261 = i > D.4258;
              if (D.4261) goto L.3;
              {
                integer(kind=4) D.4262;

                D.4262 = *m;
                j = 1;
                while (1)
                  {
                    {
                      logical(kind=4) D.4265;

                      D.4265 = j > D.4262;
                      if (D.4265) goto L.5;
                      if ((integer(kind=4)[0:] * restrict) w.data != 0B)
                        {
                          (*(integer(kind=4)[0:] * restrict) w.data)[(w.offset
+ (integer(kind=8)) i * w.dim[1].stride) + (integer(kind=8)) j] = 0;
                        }
                      L.6:;
                      L.4:;
                      j = j + 1;
                    }
                  }
                L.5:;
              }
              L.2:;
              i = i + 1;
            }
          }
        L.3:;

the n > 0 check is simplified from D.4258 = *n; i = 1; D.4261 = i > D.4258;
There's some extra guard, m > j, but that's not related so what uninit
analysis would need to see is the w.data != 0 guard but as Manu said, the
LIM pass hoists the loop invariant uses out of this conditional.

IIRC there's a related bug somewhere for LIM exposing uninitialized uses
to code paths that are not known to execute but here it's not trivial to
see the uninitializedness.

The bogus diagnostic goes away with -fno-tree-loop-im (but you usually do
not want to do that for performance reasons).  At -O3 we unswitch on
w.data != 0 but LIM already moved the access then.  One old idea is to
make sure to disable diagnostics on stmts we move for the sake of
introducing false negatives ...

[Bug tree-optimization/66459] bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized] caused by loop invariant motion (LIM)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=105937
           Keywords|                            |needs-bisection

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think the warning was fixed via the same patch which fixed PR 105937 .