• Strange warning

    From James Van Buskirk@21:1/5 to All on Sun Apr 3 04:33:55 2022
    I encountered this strange warning that is suppressed by a WRITE statement:

    D:\gfortran>type warning.f90
    module funcs
    use ISO_FORTRAN_ENV
    implicit none
    integer, parameter :: wp = REAL64
    contains
    function identity(n)
    integer, intent(in) :: n
    real(wp) identity(n,n)
    integer i

    identity = 0
    do i = 1, n
    identity(i,i) = 1
    end do
    end function identity
    end module funcs

    program main
    use funcs
    implicit none
    real(wp), allocatable :: A(:,:)

    ! write(*,*) 'This suppresses the warning.'
    A = identity(8)
    end program main

    D:\gfortran>gfortran -Wall warning.f90 -owarni
    ng
    warning.f90:24:0:

    A = identity(8)

    Warning: 'a.offset' is used uninitialized in this function [-Wuninitialized] warning.f90:24:0: Warning: 'a.dim[0].lbound' is used uninitialized in this funct
    ion [-Wuninitialized]
    warning.f90:24:0: Warning: 'a.dim[0].ubound' is used uninitialized in this funct
    ion [-Wuninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].lbound' is used uninitialized in this funct
    ion [-Wuninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].ubound' is used uninitialized in this funct
    ion [-Wuninitialized]
    warning.f90:24:0:

    A = identity(8)

    Warning: 'a.dim[0].lbound' may be used uninitialized in this function [-Wmaybe-u
    ninitialized]
    warning.f90:24:0: Warning: 'a.dim[0].ubound' may be used uninitialized in
    this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].lbound' may be used uninitialized in
    this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].ubound' may be used uninitialized in
    this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[0].ubound' may be used uninitialized in
    this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[0].lbound' may be used uninitialized in
    this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].ubound' may be used uninitialized in
    this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].lbound' may be used uninitialized in
    this f
    unction [-Wmaybe-uninitialized]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dick Hendrickson@21:1/5 to James Van Buskirk on Mon Apr 4 11:14:43 2022
    On 4/3/22 5:33 AM, James Van Buskirk wrote:
    I encountered this strange warning that is suppressed by a WRITE statement:

    D:\gfortran>type warning.f90
    module funcs
      use ISO_FORTRAN_ENV
      implicit none
      integer, parameter :: wp = REAL64
      contains
         function identity(n)
            integer, intent(in) :: n
            real(wp) identity(n,n)
            integer i

            identity = 0
            do i = 1, n
               identity(i,i) = 1
            end do
         end function identity
    end module funcs

    program main
      use funcs
      implicit none
      real(wp), allocatable :: A(:,:)

    !   write(*,*) 'This suppresses the warning.'
      A = identity(8)
    end program main

    D:\gfortran>gfortran -Wall warning.f90 -owarni
    ng
    warning.f90:24:0:

       A = identity(8)

    Warning: 'a.offset' is used uninitialized in this function
    [-Wuninitialized]
    warning.f90:24:0: Warning: 'a.dim[0].lbound' is used uninitialized in
    this funct
    ion [-Wuninitialized]
    warning.f90:24:0: Warning: 'a.dim[0].ubound' is used uninitialized in
    this funct
    ion [-Wuninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].lbound' is used uninitialized in
    this funct
    ion [-Wuninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].ubound' is used uninitialized in
    this funct
    ion [-Wuninitialized]
    warning.f90:24:0:

       A = identity(8)

    Warning: 'a.dim[0].lbound' may be used uninitialized in this function [-Wmaybe-u
    ninitialized]
    warning.f90:24:0: Warning: 'a.dim[0].ubound' may be used uninitialized
    in this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].lbound' may be used uninitialized
    in this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].ubound' may be used uninitialized
    in this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[0].ubound' may be used uninitialized
    in this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[0].lbound' may be used uninitialized
    in this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].ubound' may be used uninitialized
    in this f
    unction [-Wmaybe-uninitialized]
    warning.f90:24:0: Warning: 'a.dim[1].lbound' may be used uninitialized
    in this f
    unction [-Wmaybe-uninitialized]

    Two thoughts. Try tuning off function inlining or compile the module separately. This won't solve your problem; but, it might help the
    compiler guys understand something.

    Dick Hendrickson

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to James Van Buskirk on Mon Apr 4 12:23:41 2022
    On Sunday, April 3, 2022 at 3:34:14 AM UTC-7, James Van Buskirk wrote:
    I encountered this strange warning that is suppressed by a WRITE statement:

    Seems to be a Heisenbug:

    https://en.wikipedia.org/wiki/Heisenbug

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jfh@21:1/5 to All on Mon Apr 4 14:37:03 2022
    On Tuesday, April 5, 2022 at 7:23:43 AM UTC+12, gah4 wrote:
    On Sunday, April 3, 2022 at 3:34:14 AM UTC-7, James Van Buskirk wrote:
    I encountered this strange warning that is suppressed by a WRITE statement:
    Seems to be a Heisenbug:

    https://en.wikipedia.org/wiki/Heisenbug

    With my gfortran in an x86_64 Linux system about which gfortran -v said among many other things
    gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) there was no warning message. Perhaps it's a Gatesbug: James's D:\ makes me suspect that he was using Microsoft.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From steve kargl@21:1/5 to jfh on Mon Apr 4 22:13:41 2022
    jfh wrote:

    On Tuesday, April 5, 2022 at 7:23:43 AM UTC+12, gah4 wrote:
    On Sunday, April 3, 2022 at 3:34:14 AM UTC-7, James Van Buskirk wrote:
    I encountered this strange warning that is suppressed by a WRITE statement:
    Seems to be a Heisenbug:

    https://en.wikipedia.org/wiki/Heisenbug

    With my gfortran in an x86_64 Linux system about which gfortran -v said among many other things
    gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) there was no warning message. Perhaps it's a Gatesbug: James's D:\ makes me suspect that he was using Microsoft.
    jfh wrote:

    On Tuesday, April 5, 2022 at 7:23:43 AM UTC+12, gah4 wrote:
    On Sunday, April 3, 2022 at 3:34:14 AM UTC-7, James Van Buskirk wrote:
    I encountered this strange warning that is suppressed by a WRITE statement:
    Seems to be a Heisenbug:

    https://en.wikipedia.org/wiki/Heisenbug

    With my gfortran in an x86_64 Linux system about which gfortran -v said among many other things
    gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) there was no warning message. Perhaps it's a Gatesbug: James's D:\ makes me suspect that he was using Microsoft.

    It's a gfortran bug that can be ignored (unless one of the participants here wants to fix it).

    If one is leary of ignoring such a dire warning, then add -fno-realloc-lhs to you
    command line or allocate the array to zero size before using it on the left hand
    side.

    If one is interested in the internal add -fdump-tree-original to your command line and look at the dump file. Remove a bunch for clutter, you have

    void MAIN__ ()
    {
    struct array02_real(kind=8) a;

    a.data = 0B;

    The above is an unallocated array.

    {
    D.4265 = a.offset;
    D.4266 = a.dim[0].lbound;
    D.4267 = a.dim[0].ubound;
    D.4268 = a.dim[1].lbound;
    D.4269 = a.dim[1].ubound;

    The above is what is causing the warning as
    do the following two lines, which are irrelevant
    because ...

    D.4270 = NON_LVALUE_EXPR <D.4266>;
    D.4271 = NON_LVALUE_EXPR <D.4268>;

    D.4273 = &C.4272;
    D.4274 = *D.4273;
    D.4275 = (integer(kind=8)) D.4274 + -1;
    D.4276 = *D.4273;
    D.4277 = (integer(kind=8)) D.4276 + -1;
    {

    D.4280 = (real(kind=8)[0:] * restrict) a.data == 0B;

    ... this line sets D.4280 to true and the first if () ...

    if (D.4280) goto L.5;
    if (a.dim[0].lbound + NON_LVALUE_EXPR <D.4275> != a.dim[0].ubound) goto L.5;
    if (a.dim[1].lbound + NON_LVALUE_EXPR <D.4277> != a.dim[1].ubound) goto L.5;
    goto L.6;
    L.5:;
    if (D.4280)
    {
    D.4281 = 0;

    ... gets you here and ...

    }
    else
    {
    D.4281 = (MAX_EXPR <a.dim[0].ubound - a.dim[0].lbound, -1> + 1) * (MAX_EXPR <a.dim[1].ubound - a.dim[1].lbound, -1> + 1);
    }

    allows gfortran to set the right dope vector here ...

    D.4282 = (NON_LVALUE_EXPR <D.4277> + 1) * (NON_LVALUE_EXPR <D.4275> + 1);
    D.4283 = D.4281 != D.4282;
    a.dim[0].lbound = 1;
    a.dim[0].ubound = NON_LVALUE_EXPR <D.4275> + 1;
    a.dim[0].stride = 1;
    a.dim[1].lbound = 1;
    a.dim[1].ubound = NON_LVALUE_EXPR <D.4277> + 1;
    a.dim[1].stride = NON_LVALUE_EXPR <D.4275> + 1;
    a.offset = -NON_LVALUE_EXPR <a.dim[0].lbound> - a.dim[1].lbound * (NON_LVALUE_EXPR <D.4275> + 1);
    D.4265 = a.offset;
    D.4270 = NON_LVALUE_EXPR <a.dim[0].lbound>;
    D.4271 = NON_LVALUE_EXPR <a.dim[1].lbound>;
    a.span = 8;
    D.4284 = MAX_EXPR <(unsigned long) (D.4282 * 8), 1>;
    if (D.4280)
    {

    and finally you allocate the memory.

    a.data = (void * restrict) __builtin_malloc (D.4284);
    a.dtype = {.elem_len=8, .rank=2, .type=3};
    }
    else
    {
    if (D.4283)
    {
    a.data = (void * restrict) __builtin_realloc ((void *) a.data, D.4284);
    }
    }
    D.4264 = (real(kind=8)[0:] * restrict) a.data;
    L.6:;
    }
    identity (&a, D.4273);
    }
    }

    --
    steve

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to steve kargl on Mon Apr 4 18:27:10 2022
    On Monday, April 4, 2022 at 3:13:44 PM UTC-7, steve kargl wrote:

    (snip)

    It's a gfortran bug that can be ignored (unless one of the participants here wants to fix it).

    If one is leary of ignoring such a dire warning, then add -fno-realloc-lhs to you
    command line or allocate the array to zero size before using it on the left hand
    side.

    OK, so that explains the "is used..." messages before the "may be used" messages.

    But it seems to me also, at least possibly, a complication of reallocatable arrays and the standard.

    I wasn't sure if the OP was noting the warning, or that it goes away with
    the print statement. The latter is what makes a Heisenbug.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Van Buskirk@21:1/5 to All on Wed Apr 6 08:40:15 2022
    "gah4" wrote in message news:03035c65-dbd8-4e4d-a0fb-1cba4549a649n@googlegroups.com...

    I wasn't sure if the OP was noting the warning, or that it goes away with
    the print statement. The latter is what makes a Heisenbug.

    The first thing I tried was allocating the array to zero size, but then
    I noticed that other arrays that weren't so preallocated didn't
    present this issue. I tried a few other commands to see whether
    any of them suppressed the warning and found the WRITE did
    the trick.

    Thanks to sgk for his thorough analysis. It's bugs like this one
    that make me wonder about how many latent bugs must be
    present in any notrivial software package.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From steve kargl@21:1/5 to James Van Buskirk on Thu Apr 7 17:22:08 2022
    James Van Buskirk wrote:

    "gah4" wrote in message news:03035c65-dbd8-4e4d-a0fb-1cba4549a649n@googlegroups.com...

    I wasn't sure if the OP was noting the warning, or that it goes away with
    the print statement. The latter is what makes a Heisenbug.

    The first thing I tried was allocating the array to zero size, but then
    I noticed that other arrays that weren't so preallocated didn't
    present this issue. I tried a few other commands to see whether
    any of them suppressed the warning and found the WRITE did
    the trick.

    Thanks to sgk for his thorough analysis. It's bugs like this one
    that make me wonder about how many latent bugs must be
    present in any notrivial software package.

    I've looked at this before, but it is in the area of the compiler
    that I do not know very well. It also happens to be one of the
    more complicated parts. The pseudo-code seems simple:

    gfortran currently does something like:

    save dope vector to temporary variables (danger, will robertson)

    if (not allocated) then
    do allocation
    else
    do re-allocation
    end if

    gfortran should be doing soemthing like

    if (not allocated) then
    do allocation
    else
    check if reallocation is needed
    save dope vector to temporary variables
    do re-allocation
    end if

    Things get complicated with deep copies of defined types and classes.

    --
    steve

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)