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

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Tue, May 12, 2009 at 07:29:29PM -0700, Jerry DeLisle wrote:
> Steve Kargl wrote:
> >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.
> 
> It is covered in the standard.  See my comments below.
> 
>   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).
> >
> >
> Jakub,
> 
> I very much appreciate your effort on this.
> 
> F2003 standard says that FMT=format
> 
> R914 format is default-char-expr
>             or label
>             or *
> 
> It seems clear to me that anything other then the three cases in R914 is 
> invalid Fortran and we should throw a diagnostic.
> 
> I see the exact same requirement in F95, and F2008
> 
> The F77 standard uses different language but it is equivalent, so this 
> suggests it is not a legacy behaviour.
> 
> Also, it is clear that if a character array is specified, the format 
> specifiers begin with the left most character in the element.  Elements are 
> concatenated in array element order, forming one string.
> 
> If a single element is specified it is treated as a single string and the 
> formatting does not extend past that element.  In other words, the length 
> of the single element string is the size of the character element of the 
> array.
> 

Jerry,

I almost sent Jakub an identical email, but knowing his contributions
to gfortran I'm assuming he's well aware of what the standard says.  I don't
have g77 installed so I can't test if this is a g77 compatibility issue.
Jakub's code gives

REMOVE:kargl[205] gfc4x -c kl.f90 
kl.f90:4.15:

 write (*, fmt=a(2,3)) 1
               1
Warning: Extension: Non-character in FORMAT tag at (1)
kl.f90:5.15:

 write (*, fmt=b(3,2)) 1
               1
Warning: Extension: Non-character in FORMAT tag at (1)

The issue that concerns me (and I haven't had time to check) is
'can one pack a Hollerith into a complex type?', and 'is this some
stupid g77 extension?'.  Dominique's test case, I believe, touches
upon the problem.

Personally, I think that this should be converted to an error.  
If it's permitted for compatibility, then gfortran should hide
behind -fnonstd-fmt (or similarly nemaed option).

-- 
Steve