inconsistent treatment of TYPE vs. REAL in 'stream' write with Intel big-endian I/O conversion

I'm seeing different bit patterns when I write a REAL variable to file as component of a TYPE as opposed to when it's just a REAL in stream output while using the -convert big_endian option.

Given the following small program, which opens a file in 'stream' access mode and the proceeds to write two REAL's:

$ cat stream-write.f90
PROGRAM foo
  IMPLICIT NONE
  TYPE bar
    real :: x
  END TYPE bar
  INTEGER, PARAMETER :: file_id = 20
  INTEGER :: ierror
  REAL :: y
  TYPE(bar) :: z

  OPEN(file_id, file="bsob.bin", iostat=ierror, action='write', &
       form='unformatted', access='stream', status='replace')

  y = 2.0
  z%x = y
  WRITE(file_id) y
  WRITE(file_id) z
  FLUSH(file_id)
  CLOSE(file_id)
END PROGRAM foo

and compiling with

$ ifort --version
ifort (IFORT) 14.0.2 20140120
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

$ ifort -convert big_endian -o stream-write stream-write.f90
$ ./stream-write
$ hexdump bsob.bin
0000000 0040 0000 0000 4000
0000008


One can see that the two written quantities are of different endianness.

I tested the same program with gfortran 4.7.2 and got consistent bit patterns, i.e.:

$ gfortran -fconvert=big-endian -o stream-write stream-write.f90
$ ./stream-write
$ hexdump bsob.bin
0000000 0040 0000 0040 0000
0000008


Is this intended? I realize the standard specifies pretty little when it comes to unformatted output. Also programs to read the data compiled by the same compiler could probably read it if TYPE/non-TYPE arguments
match the previous WRITEs. But the observed doesn't exactly match my expections.

The system involved is a Xeon E5-2665 with Linux 3.11 running in x86_64 mode.

Thomas