User account creation filtered due to spam.

Bug 35719 - pointer to zero sized array not associated
Summary: pointer to zero sized array not associated
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/fortran/2008-05...
Keywords: patch, wrong-code
Depends on:
Blocks:
 
Reported: 2008-03-27 16:14 UTC by Dick Hendrickson
Modified: 2008-05-12 11:27 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.4.0
Known to fail: 4.3.1
Last reconfirmed: 2008-03-27 16:53:24


Attachments
Trial patch (472 bytes, patch)
2008-05-06 21:24 UTC, Thomas Koenig
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Hendrickson 2008-03-27 16:14:07 UTC
The ASSOCIATED function returns FALSE when its argument is a
pointer to a zero-sized array.

Dick Hendrickson

      program try_mf1053

! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]

      call       mf1053 (  1,   2,   3,   4)
      end

      SUBROUTINE MF1053 (nf1, nf2, nf3, nf4)
      INTEGER, pointer :: ILA(:,:)
      INTEGER, target  :: ILA1(NF2,NF4:NF3)

      ILA => ILA1

      if (ASSOCIATED (ILA, ILA1(NF1:NF2,NF4:NF3) ) ) print *, "1 bad"
      if ( .not. ASSOCIATED(ILA) )  print *, "2 bad"

      END SUBROUTINE

C:\g_experiments\gfortran>gfortran mf1053.f

C:\g_experiments\gfortran>a
 2 bad
Comment 1 Tobias Burnus 2008-03-27 16:53:24 UTC
Confirm. Thanks for finding this bug.
Comment 2 Thomas Koenig 2008-05-04 21:29:08 UTC
The problem is that we set ila1 to a null pointer if its
size is zero:

    D.647 = size.6 * 4;
    if (D.647 < 0)
      {
        _gfortran_runtime_error (&"Attempt to allocate a negative amount of memory."[1]{lb: 1 sz: 1});
      }
    if (D.647 == 0)
      {
        D.648 = 0B;
      }
    else
      {
        D.648 = __builtin_malloc (D.647);
        if (D.648 == 0B)
          {
            _gfortran_os_error (&"Memory allocation failed"[1]{lb: 1 sz: 1});
          }
      }
    ila1 = (integer(kind=4)[0:D.644] *) D.648;

It isn't clear to me why we do this (maybe as a debugging aid?).
Comment 3 Tobias Burnus 2008-05-05 05:46:22 UTC
(In reply to comment #2)
> The problem is that we set ila1 to a null pointer if its
> size is zero: [...]
> It isn't clear to me why we do this (maybe as a debugging aid?).

Well, if we don't assign anything, the memory content is not well defined. Doing than   associated(ptr[, otherPtr])  gives then a random result including not-associated.  Currently, ptr.data == NULL -> unassociated and ptr.data != NULL => associated works well, except for zero-sized arrays.

One possibility is to allocate something for zero-sized arrays, e.g. one element. The array bounds ensure than that the program still knows that the size of the array is zero. The extra allocation wastes memory, but usually one element is quite small and zero-sized arrays are not very common.
Comment 4 Thomas Koenig 2008-05-05 18:24:11 UTC
(In reply to comment #3)

> One possibility is to allocate something for zero-sized arrays, e.g. one
> element. The array bounds ensure than that the program still knows that the
> size of the array is zero. The extra allocation wastes memory, but usually one
> element is quite small and zero-sized arrays are not very common.

I agree in principle; but we could also allocate a single array,
like we do for ALLOCATE.

This is probably the cleanest solution.

Comment 5 Thomas Koenig 2008-05-06 21:24:44 UTC
Created attachment 15587 [details]
Trial patch

Here's an attempt at a patch, which should do the
right thing at least for this case.
Comment 6 Janne Blomqvist 2008-05-09 06:15:57 UTC
Another solution is to have status flags for allocated and associated in the descriptor, IIRC at least Pathscale does this.

Aren't there actually free bits left in the dtype flag that gfortran could use, without requiring to change the descriptor?
Comment 7 Thomas Koenig 2008-05-09 18:34:18 UTC
(In reply to comment #6)
> Another solution is to have status flags for allocated and associated in the
> descriptor, IIRC at least Pathscale does this.
> 
> Aren't there actually free bits left in the dtype flag that gfortran could use,
> without requiring to change the descriptor?

We will need to change the descriptor to fix PR 35718.  Unfortunately,
dtype shares space with the size, so by introducing additional bits
we would be incompatible, and restrict the size of derived types further.

Time for a "what we want to fix with the new array descriptor"
meta-PR?

Comment 8 Thomas Koenig 2008-05-11 20:29:39 UTC
Subject: Bug 35719

Author: tkoenig
Date: Sun May 11 20:28:52 2008
New Revision: 135187

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135187
Log:
2008-05-11  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/35719
	* trans.c (gfc_call_malloc): If size equals zero, allocate one
	byte; don't return a null pointer.

2008-05-11  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/35719
	* gfortran.dg/associated_5.f90:  New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/associated_5.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans.c
    trunk/gcc/testsuite/ChangeLog

Comment 9 Thomas Koenig 2008-05-11 20:39:48 UTC
Fixed on trunk.

I don't think this really needs to be fixed on 4.3, so
I am closing this.
Comment 10 Janne Blomqvist 2008-05-12 11:27:26 UTC
>Time for a "what we want to fix with the new array descriptor"
>meta-PR?

I started a wiki page for this, with a few issues from the top of my head: http://gcc.gnu.org/wiki/ArrayDescriptorUpdate