This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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)

Steve Kargl wrote:
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).


Hmm, g77 does compile the following without complaint.

      subroutine foo (a)
      complex :: a(1:5,1:10)
c      complex :: b(:,:)
      write (*, fmt=a) 1
c      write (*, fmt=b(3,2)) 1
      end subroutine

In this case maybe give an error unless -std=legacy, since it goes against all standards from f77 on, and warn otherwise. I would sure hope nobody is actually using this.

Jakub, if you are aware of s specific user issue with all this, let us know, If not, I would like to see a hard error and be done with this.

Jerry

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