(Re)allocation of allocatable arrays on assignment - F2003

[Tobias Burnus]

  Dear Paul,

Paul Richard Thomas wrote:
>> b) The test case fails for me for:
>>
>>   if (any (b .ne. a)) call abort
>>
>> as "a(10)" == 0 while "b(10)" == -134744073.
> That is very mysterious.

I think something is fishy about the following:

         D.1547 = a.dim[0].lbound;
         D.1548 = a.dim[0].ubound;
         {
           D.1548 = a.dim[0].ubound - a.dim[0].lbound;
               b.data = (void * restrict) __builtin_malloc (D.1555 * 4);
         }
           S.2 = D.1547;
           while (1)
             {
               if (S.2 > D.1548) goto L.2;

The loop should be:
           S.2 = a.lbound;
           while (1)
             {
               if (S.2 > a.ubound) goto L.2;
but it effectively is
           S.2 = a.lbound;
           while (1)
             {
               if (S.2 > (a.ubound-a.lbound)) goto L.2;

Which for lbound == 1 misses the last element - which happens to be "0" 
in your case. Zero is a bad choice as memory is often initialized to 
zero ...

>> f) The following is valid Fortran 2008 (LHS polymorphic but allocatable),
>> invalid Fortran 2003 and currently rejected (LHS is polymorphic):
> I'll do F2003 first.

That's fine - I was just checking whether it silently fails; 
fortunately, it is rejected at compile time and thus deferring does not 
even cause a wrong-code problem with F2008 code.

> The most worrying of the above is the failure of
>>   if (any (b .ne. a)) call abort
> I don't quite know who to deal with that since it works for me.

I assume the reason is that the last element is "0" and your memory 
seems to be initialized by zero. I think one reason that I get more 
often non-zero values than you is that I set the following environment 
variables - in particular the first one:

export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
export MALLOC_CHECK_=2

Tobias