[Bug fortran/65125] New: ISO_10646 characters and transfer statement

["zbeekman at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 65125
           Summary: ISO_10646 characters and transfer statement
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zbeekman at gmail dot com

Created attachment 34810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34810&action=edit
reproducer program

I am on OS X Yosemite, 10.10.2 with a 64bit Intel CPU. 
Gfortran is version: NU Fortran (Homebrew gcc49 4.9.2_1 --enable-fortran) 4.9.2

I'm trying to make a portable json library that will behave gracefully when
encountering compilers whose ISO_10646 support is lacking. To achieve this, for
certain variables use the character kind defined as:

integer, parameter :: CK =
merge(tsource=selected_char_kind('ISO_10646'),fsource=selected_char_kind('DEFAULT'),mask=selected_char_kind('ISO_10646')
/= -1)

The error handling of the library needs a way to both DEFAULT and ISO_10646
characters, but overloading the error handling routine to have two interfaces
won't work because when ISO_10646 *isn't* supported the two specific routines
will have matching interfaces. As a work around, I would like to print the hex
representation of characters that are `kind=CK` that is possibly ISO_10646 or
DEFAULT. To accomplish this I have written a function `char_to_hex(c)` to try
to print the hex representation of the character. To do this, I am using
`transfer()` to puth the passed in single character into a sufficiently large
integer, and using the `z8.8` edit descriptor to convert to the function result
which is ALWAYS represented in `kind='DEFAULT'` characters (so that I can
safely pass it to the error handling routine).

The problem is that it appears the transfer statement is only writing 2 nibbles
(one byte) to the integer, or  the z8.8 is only fetching two nibbles of the
int32 integer. Forexample, the output for a Unicode SNOWFLAKE is 0x000000E2
when it should be: 0x00E29d84. I think the problem is the transfer statement,
since I observe some strange behavior if I modify the char_to_hex() function to
accept len=4 character strings, and adjust the inputs to be the character in
question followed by 4 spaces, and adjust the storage container to int64 and
edit descriptor to z18.18. Now SNOWFLAKE prints out as 0x0x0000009D000000E2:
two most significant nibbles are on the right, then 6 zero nibbles to the left,
the 3rd and 4th most significant nibbles, then more zeroes.

Am I missing something? If not, I think this is a bug.