https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82511
--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Oct 13, 2017 at 01:39:26AM +0000, foreese at gcc dot gnu.org wrote:
>
> Fritz Reese <foreese at gcc dot gnu.org> changed:
>
> Under other DEC compilers, it seems STRUCTUREs are to be treated consistently
> with derived types in regards to I/O lists. That is to say, a structure
> variable is treated as if each of its named components was listed on the I/O
> list. (Even with UNIONs/MAPs, each named component is to be treated as having
> been listed in place of the DEC RECORD containing it, so that the last
> component written to within overlapping MAPs takes effect. Yikes.)
>
> I believe both the code in the attachment and the "intended code" (writing to
> bucket.c16 instead of bucket) should be accepted, whereas they both ICE
> currently.
>
> I will look into it.
I actually misread the code. I thought it was
program bug
structure /bckt/
union
map
character*16 c16
end map
end union
end structure
record /bckt/ bucket
character(len=16) :: rec1 = 'ABCDEFGHIJKLMNOP'
100 format(A16)
read(rec1, 100) bckt
end program bug
where one is trying read into the definition of the structure.
Is the above suppose to compile? Because it does. A simple
program with a Fortran derived type fails.
type bar
integer i
end type bar
character(len=10) :: str ='123'
read(str,*) bar
end
# gfcx -c b.f
b.f:5:21:
read(str,*) bar
1
Error: Derived type 'bar' cannot be used as a variable at (1)
I was thinking the bckt should be handled in the same manner
as bar.
