Strange warning

[James Van Buskirk]

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]

[Dick Hendrickson]

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

[gah4]

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

[jfh]

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.

[steve kargl]

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

[gah4]

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.

[James Van Buskirk]

"gah4" wrote in message
news:03035c65-dbd8-4e4d...@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.

[steve kargl]

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