This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix FMT= with CHARACTER arrays (PR fortran/39865, take 2)

On Tue, May 12, 2009 at 10:28:15PM +0200, Jakub Jelinek wrote:
> On Tue, May 12, 2009 at 11:41:58AM -0700, Steve Kargl wrote:
> > > And this updated patch instead should fix it fully, take care of the needed
> > > packing if the array is not packed.
> > > To avoid code duplication, I'm using gfc_conv_array_parameter function
> > > which does almost what we want, except that it doesn't compute the array
> > > size and the return value in se->expr isn't something from which it could be
> > > computed.  So the patch adds an optional size outgoing argument, if
> > > non-NULL, the size will be computed, all older callers just pass NULL.
> The patch also changes behavior for the e->rank == 0 (i.e. element of an
> array with type other than CHARACTER) case.  Previously for the element
> case the FMT= string would start at the address of the element and go on
> until end of the array, would generally work just with variables, not
> function calls.
> The patch as posted changes the size to the size of the element.
> This isn't something that is covered by the standard, so I'm not sure what
> should be done in that case.  Consider:
> subroutine foo (a,b)
> complex :: a(1:5,1:10)
> complex :: b(:,:)
> write (*, fmt=a(2,3)) 1
> write (*, fmt=b(3,2)) 1
> end subroutine
> Is the first write supposed to use format starting at &a[11] (C notation)
> with the length sizeof(complex) * 39, or with the length sizeof(complex)?
> What about the second case, especially if b isn't a packed array?  Shall
> the size in that case include any gaps in the array?

Well, this is an extension to the standard that I've never used.
If this extension is intended for backwards compatibility with
g77, then gfortran would need to implement that behavior.  Otherwise,
I'd be in favor of disallowing this construct.

In taking a quick peek at the code in io.c, I'll need more time to
understand what this fmt= means.  However, my gut feeling is that
the starting address would be &a[8] (ie., 2nd column, 3rd row)
with a maximum length of sizeof(complex) * (50 - 8).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]