Bug 91442 - Wrong "may be used uninitialized" warning with allocation on assignment
Summary: Wrong "may be used uninitialized" warning with allocation on assignment
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 8.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency tree / graph
 
Reported: 2019-08-14 11:19 UTC by Ignacio Fernández Galván
Modified: 2021-09-03 12:59 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2019-08-14 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ignacio Fernández Galván 2019-08-14 11:19:15 UTC 
Simple test case:

!=======================
program test
character(len=:), allocatable :: string
string='Hello world!'
write(6,*) string
end program
!=======================

Compile with "-Wall":

test.f90:3:0:

 string=''
 
Warning: ‘.string’ may be used uninitialized in this function [-Wmaybe-uninitialized]

Adding "-O1" removes the warning, though.
Comment 1 Richard Biener 2019-08-14 12:15:56 UTC 
test ()
{
  integer(kind=8) .string;
  character(kind=1)[1:.string] * string;

  string = 0B;
  {
    integer(kind=8) D.3904;
    integer(kind=8) D.3905;

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


see how we run into L.1 testing .string which was not set?  At -O0 we
didn't figure we never execute this path.  I suggest to initialize .string to zero?

The early warning pass sees (conditionally executed)

  <bb 4> :
  if (.string_11(D) == 12)
    goto <bb 6>; [INV]
  else
    goto <bb 5>; [INV]

thus the "may" warning.  Alternatively just elide this check.
Comment 2 paul.luckner 2020-12-03 12:09:11 UTC 
Same is true for any other intrinsic data type. 

Test case for integer array:

program test
  implicit none
  integer, allocatable :: i(:)
  i = [1]
end program

Compilation and warning:
$ gfortran -Wall -g3 -fcheck=all -fuse-ld=bfd a.f90

    4 |   i = [1]
      | 
Warning: ‘i.offset’ may be used uninitialized in this function [-Wmaybe-uninitialized]
a.f90:4:0: Warning: ‘i.dim[0].lbound’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Comment 3 Thomas Schwinge 2021-09-03 12:58:24 UTC 
(In reply to Ignacio Fernández Galván from comment #0)
> character(len=:), allocatable :: string
> string='Hello world!'

Is that PR56670?
Comment 4 Thomas Schwinge 2021-09-03 12:59:15 UTC 
(In reply to paul.luckner from comment #2)
>   integer, allocatable :: i(:)
>   i = [1]

Is that PR77504?