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
Confirm. Thanks for finding this bug.
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?).
(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.
(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.
Created attachment 15587 [details] Trial patch Here's an attempt at a patch, which should do the right thing at least for this case.
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?
(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?
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
Fixed on trunk. I don't think this really needs to be fixed on 4.3, so I am closing this.
>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