Bug 56670 - Allocatable-length character var causes bogus warning with -Wuninitialized
Summary: Allocatable-length character var causes bogus warning with -Wuninitialized
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
: 60122 88455 (view as bug list)
Depends on:
Blocks: Wuninitialized 68241 45170
  Show dependency treegraph
 
Reported: 2013-03-20 20:38 UTC by Rich Townsend
Modified: 2019-03-23 15:32 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-03-22 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Townsend 2013-03-20 20:38:51 UTC
Compiling this short test case with the -Wall option:

program uninit_test

  implicit none

  character(LEN=:), allocatable :: name_format

  name_format = ''

end program uninit_test

...causes the following bogus warning:

uninit_test.f90: In function ‘uninit_test’:
uninit_test.f90:7:0: warning: ‘.name_format’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   name_format = ''
 ^

(Note also that the warning arises in the main program, and not in a function as the message suggests).

gfortran -v:

Using built-in specs.
COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.8.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.8.0 20130314 (experimental) (GCC)
Comment 1 Dominique d'Humieres 2014-03-22 15:46:34 UTC
Confirmed from 4.6 to trunk (4.9).
Comment 2 Manuel López-Ibáñez 2015-02-23 17:57:13 UTC
Fix blocks/depends list.
Comment 3 Mikael Morin 2015-08-07 20:26:04 UTC
Possibly related: PR60500
Comment 4 Manuel López-Ibáñez 2016-09-07 20:00:20 UTC
(In reply to Rich Townsend from comment #0)
> ...causes the following bogus warning:

If you compile with -fdump-tree-all-all-lineno and look at test.f90.004t.gimple you'll see that gfortran generates:

      [test.f90:5:0] name_formatD.3382 = 0B;
      [test.f90:7:0] {
        integer(kind=4)D.8 D.3383;

        [test.f90:7:0] if (name_formatD.3382 != 0B) goto L.1D.3384; else goto <D.3391>;
...
        L.1D.3384:
        [test.f90:7:0] if (.name_formatD.3381 == 0) goto L.2D.3385; else goto <D.3392>;

If the last line is reached, then .name_format is used uninitialized. This cannot happen here, because the first 'if' is always false. However, GCC does not know that without the analysis done when using optimization. With -O1 there is no warning.

(That code is quite strange, why test for != 0B after initializing it to 0B?)

> uninit_test.f90: In function ‘uninit_test’:
> uninit_test.f90:7:0: warning: ‘.name_format’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
>    name_format = ''
>  ^
> 
> (Note also that the warning arises in the main program, and not in a
> function as the message suggests).

This is the output in a modern gfortran (with colors!):

test.f90:7:0:

   name_format = ''
 ^
Warning: ‘.name_format’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Comment 5 janus 2018-07-02 08:43:18 UTC
Related test case:


subroutine sub(strIn, strOut)

   character(len=10) :: strOut
   character(len=100) :: strIn

   associate (substr => strIn(1:10))

      strout = substr

   end associate

end



Compiling this with "gfortran-8 -Wall" yields:

       strout = substr
 
Warning: ‘.substr’ is used uninitialized in this function [-Wuninitialized]


gfortran-7 and earlier doesn't show this warning.
Comment 6 janus 2018-07-02 09:13:19 UTC
(In reply to janus from comment #5)
> Related test case:

This is probably a separate problem, since it is also connected to a wrong-code bug, see PR 86372.
Comment 7 Dominique d'Humieres 2018-12-23 12:21:01 UTC
*** Bug 60122 has been marked as a duplicate of this bug. ***
Comment 8 Dominique d'Humieres 2019-03-23 15:06:22 UTC
*** Bug 88455 has been marked as a duplicate of this bug. ***
Comment 9 Dominique d'Humieres 2019-03-23 15:10:37 UTC
The dump-tree-original shows

...
    if (name_format != 0B) goto L.1;
    name_format = (character(kind=1)[1:.name_format] *) __builtin_malloc (1);
    goto L.2;
    L.1:;
    if (.name_format == 0) goto L.2;
    name_format = (character(kind=1)[1:.name_format] *) __builtin_realloc ((void *) name_format, 1);
    L.2:;
    .name_format = 0;
...