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.