Bug 66459 - bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
Summary: bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 5.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-08 11:02 UTC by Mario Baumann
Modified: 2017-08-24 08:45 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-06-08 00:00:00


Attachments
Fortran Fixed Form File (186 bytes, text/plain)
2015-06-08 11:02 UTC, Mario Baumann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mario Baumann 2015-06-08 11:02:27 UTC
Created attachment 35716 [details]
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
Comment 1 Mikael Morin 2015-06-08 14:46:36 UTC
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.
Comment 2 Dominique d'Humieres 2015-11-04 17:49:54 UTC
> Possibly related bug: PR60500

Likely, but I get the warning for this PR for 4.5.4, but not 4.4.7, while the warnings for PR60500 appear only for 4.7.3.
Comment 3 Manuel López-Ibáñez 2016-09-07 20:23:25 UTC
If you do

gfortran -Wuninitialized test.f90 -fdump-tree-all-all-lineno -O1

and look at test.f90.162t.uninit1, we see:

  # .MEM_24 = PHI <.MEM_15(D)(28), .MEM_68(37)>
  # w$dim$1$stride_46 = PHI <w$dim$1$stride_85(D)(28), [test.f90:9:0] w$dim$1$stride_22(37)>
  # w$offset_26 = PHI <w$offset_16(D)(28), [test.f90:9:0] w$offset_56(37)>

but this code is transformed by optimization. The unoptimized SSA contains:

  [test.f90:9:0] # VUSE <.MEM_18>
  _22 = [test.f90:9:0] *m_21(D);
  [test.f90:9:0] _23 = MAX_EXPR <_22, 0>;
  [test.f90:9:0] _24 = (integer(kind=8)D.9) _23;
...
  [test.f90:9:0] _39 = _24;
...
  [test.f90:9:0] _68 = ~_39;
...
  [test.f90:9:0] wD.3400.offsetD.3387 = _68;

and the gimple generated by Fortran contains something similar:

            [test.f90:9:0] D.3429 = [test.f90:9:0] *mD.3381;
            [test.f90:9:0] D.3430 = MAX_EXPR <D.3429, 0>;
            [test.f90:9:0] D.3402 = (integer(kind=8)D.9) D.3430;

It seems that *mD.3381 is not initialized.

(It is very strange that gfortran converts user-defined variables to lowercase. It makes reading the dumps more difficult. It also does many unnecessary copies, making the code harder to analyze.)