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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #13 from Jerry DeLisle  ---
OK, thanks for getting the others input on this. It will be a bit tricky to do.

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

[walt.brainerd at gmail dot com]

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

--- Comment #12 from Walt Brainerd  ---
I made a misstatement in my previous message.
gfortran 7.0.1 does not accept this.

Sorry, my "test" was not correct.

I am going to post a query to comp-fortran-90 to see what others think.

On Fri, Jun 9, 2017 at 12:08 PM, Walt Brainerd 
wrote:

> I am not sure what you changed your mind from or to :-).
>
> Yes, the assignment is invalid because r is real the the rhs is type
> B_type.
>
> And, yes, the type of the io list item is B_type.
>
> However, the uncommented WRITE statement is valid, and,
> in the absence or a DT edit descriptor, the components (one real) are
> written in order, so 20.0 is written with f4.1 format.
>
> ifort 2017 and gfortran 7.01. both agree with this (maybe the latter
> because of you).
>
> If you disagree with this, I would be happy to solicit opinions from more
> experts.
>
> On Thu, Jun 8, 2017 at 10:05 PM, jvdelisle at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
>>
>> --- Comment #10 from Jerry DeLisle  ---
>> After a lot of head scratching I think I am changing my mind on this one.
>>
>> If one tries to assign to a real variable as in:
>>
>> program test_b_write_dt_mod
>>
>>use :: B_write_dt_mod
>>implicit none
>>
>>type(B_type) :: x != B_type(20.0)
>>real :: r
>>
>>r = B_type(20.0)
>>
>>write (unit=*, fmt="(f4.1)") B_type(20.0)
>>!write (unit=*, fmt="(f4.1)") x
>>
>> end program test_b_write_dt_mod
>>
>> The effective item is of type B_type not real and the assignment to r is
>> rejected.
>>
>> So I believe the effective type in the write statement is likewise
>> derived type
>> ad not real.
>>
>> My thinking is this PR is invalid.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>
>
>
>
> --
> Walt Brainerd
>

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

[walt.brainerd at gmail dot com]

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

--- Comment #11 from Walt Brainerd  ---
I am not sure what you changed your mind from or to :-).

Yes, the assignment is invalid because r is real the the rhs is type B_type.

And, yes, the type of the io list item is B_type.

However, the uncommented WRITE statement is valid, and,
in the absence or a DT edit descriptor, the components (one real) are
written in order, so 20.0 is written with f4.1 format.

ifort 2017 and gfortran 7.01. both agree with this (maybe the latter
because of you).

If you disagree with this, I would be happy to solicit opinions from more
experts.

On Thu, Jun 8, 2017 at 10:05 PM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
>
> --- Comment #10 from Jerry DeLisle  ---
> After a lot of head scratching I think I am changing my mind on this one.
>
> If one tries to assign to a real variable as in:
>
> program test_b_write_dt_mod
>
>use :: B_write_dt_mod
>implicit none
>
>type(B_type) :: x != B_type(20.0)
>real :: r
>
>r = B_type(20.0)
>
>write (unit=*, fmt="(f4.1)") B_type(20.0)
>!write (unit=*, fmt="(f4.1)") x
>
> end program test_b_write_dt_mod
>
> The effective item is of type B_type not real and the assignment to r is
> rejected.
>
> So I believe the effective type in the write statement is likewise derived
> type
> ad not real.
>
> My thinking is this PR is invalid.
>
> --
> You are receiving this mail because:
> You reported the bug.

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
After a lot of head scratching I think I am changing my mind on this one.

If one tries to assign to a real variable as in:

program test_b_write_dt_mod

   use :: B_write_dt_mod
   implicit none

   type(B_type) :: x != B_type(20.0)
   real :: r

   r = B_type(20.0)

   write (unit=*, fmt="(f4.1)") B_type(20.0)
   !write (unit=*, fmt="(f4.1)") x

end program test_b_write_dt_mod

The effective item is of type B_type not real and the assignment to r is
rejected.

So I believe the effective type in the write statement is likewise derived type
ad not real.

My thinking is this PR is invalid.

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Jerry DeLisle  ---
9.6.4.8.4 Resolving defined input/output procedure references

In paragraph 2, there are two conditions that BOTH must be satisfied for a user
defined procedure to be used:

Condition 1:

 a) list directed, namelist, or unformatted
 or
 b) formatted and the edit descriptor corresponds to the effective item and is
DT

Condition 2:

 a) effective item as a suitable type bound procedure
 or
 b) a generic interface is accessible

With the specific case given in this PR:

write (unit=*, fmt="(f4.1)") B_type(20.0)

The "effective item" is key here. My interpretation is that it is the kind=real
number 20.0 and that th B_type(20.0) needs to be further resolved in io.c

Confirming this bug.

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(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

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

[walt.brainerd at gmail dot com]

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

--- Comment #7 from Walt Brainerd  ---
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.


On Sun, Mar 12, 2017 at 2:28 PM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
>
> --- Comment #6 from Jerry DeLisle  ---
> (In reply to Walt Brainerd from comment #1)
> > Forgot to add:
> >
> > Pls see F08 std 9.6.3(7) 2nd bullet
>
> I see:
>
> BULLET: If a list item of derived type in a formatted input/output
> statement is
> not processed by a defined input/output procedure, that list item is
> treated as
> if all of the components of the list item were specified in the list in
> component order; those components shall be accessible in the scoping unit
> containing the
> input/output statement and shall not be pointers or allocatable.
>
> In your case you have provided a defined output procedure. So this is what
> it
> is trying to do. see 'if' ... 'not processed by' above.
>
> Do I have the right place in the standard you were looking at? Maybe we
> are not
> interpreting that correctly?
>
> --
> You are receiving this mail because:
> You reported the bug.
>

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
(In reply to Walt Brainerd from comment #1)
> Forgot to add:
> 
> Pls see F08 std 9.6.3(7) 2nd bullet

I see:

BULLET: If a list item of derived type in a formatted input/output statement is
not processed by a defined input/output procedure, that list item is treated as
if all of the components of the list item were specified in the list in
component order; those components shall be accessible in the scoping unit
containing the
input/output statement and shall not be pointers or allocatable.

In your case you have provided a defined output procedure. So this is what it
is trying to do. see 'if' ... 'not processed by' above.

Do I have the right place in the standard you were looking at? Maybe we are not
interpreting that correctly?

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #5 from Jerry DeLisle  ---
Walt, you are starting to get too clever for me. ;)

Its true, its a derived type. I wonder if the frontend should resolve it to a
real before passing to the library?

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

[walt.brainerd at gmail dot com]

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

--- Comment #4 from Walt Brainerd  ---
Sorry, I cut the example down one step too many.
Please try this one. It works OK without all the stuff
related to DTIO.

BTW, I didn't mention: this is on Windows 10.

module B_write_dt_mod

   implicit none
   private

   type, public :: B_type
  real :: amount
   end type B_type

   interface write (formatted)
  procedure :: Write_b_real
   end interface

   public :: write (formatted)

contains

subroutine Write_b_real &
   (amount, unit, b_edit_descriptor, v_list, iostat, iomsg)

   class (B_type), intent(in) :: amount
   integer, intent(in) :: unit
   character (len=*), intent(in) :: b_edit_descriptor
   integer, dimension(:), intent(in) :: v_list
   integer, intent(out) :: iostat
   character (len=*), intent(inout) :: iomsg
   write (unit=unit, fmt="(a)", iostat=iostat) "444.44"

end subroutine Write_b_real

end module B_write_dt_mod

program test_b_write_dt_mod

   use :: B_write_dt_mod
   implicit none

   write (unit=*, fmt="(f4.1)") B_type(20.0)

end program test_b_write_dt_mod

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

[walt.brainerd at gmail dot com]

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

--- Comment #3 from Walt Brainerd  ---
Sorry, when trying to cut the bug to the smallest problem,
I went too far. I will start again.

On Sat, Mar 11, 2017 at 6:52 PM, dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
>
> Dominique d'Humieres  changed:
>
>What|Removed |Added
> 
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2017-03-12
>  Ever confirmed|0   |1
>
> --- Comment #2 from Dominique d'Humieres  ---
> Works for me (outputs 5.5 at run time) on x86_64-apple-darwin from 4.3.1
> up to
> trunk (7.0 r246000).
>
> --
> You are receiving this mail because:
> You reported the bug.

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-12
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Works for me (outputs 5.5 at run time) on x86_64-apple-darwin from 4.3.1 up to
trunk (7.0 r246000).

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

[walt.brainerd at gmail dot com]

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

--- Comment #1 from Walt Brainerd  ---
Forgot to add:

Pls see F08 std 9.6.3(7) 2nd bullet