This is the mail archive of the gcc-bugs@gcc.gnu.org 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]

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009

--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Walt Brainerd from comment #7)
> I took "not processed by" to mean that there is no DT edit descriptor
> corresponding to it.
> 
> But I see how this might be interpreted otherwise.
> 
> Intel agrees with me FWIW.
> 
> Maybe this is a question for J3 (or perhaps first, c.l.f?).
> 
> Thanks for thinking about this.
> 

Thanks for helping me see the other side.  If list formatted (fmt=*), the I/O
operations are driven by the I/O list, so this is clear as the user defined
procedures are used if present.

Generally, formatted I/O is driven by the format string. This gets interesting
with something like '(i5, a4, DT)' where the IO list contains two derived
types. If the first derived type contains two components, then it would be
expanded to its components and these would fulfill i5 and a4. Then the DT would
process the second derived type in the list.  

If the first derived type has three components, there is a mismatch to the IO
list. gfortran does the expansion of the components at compile time because it
can not always know the format string until run time so the decision is based
off the existence of user defined procedures.

Example:

type a
  integer      :: num
  character(5) :: str
end type a

type b
  some stuff
end type b

type(a) :: data1
type(b) :: data2
sfmt = "(i5,1x,a5,1x,DT)"
write(10, fmt=sfmt) data1, data2

Interesting question

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