LI74264: COMPILATION ERROR WITH Q64

March 2009 Update for XL C/C++ Advanced Edition for Blue Gene/P, V9.0
August 2009 Update for XL C/C++ Advanced Edition for Blue Gene/P, V9.0
May 2010 Update for XL C/C++ Advanced Edition for Blue Gene/P, V9.0
December 2010 Update for XL C/C++ Advanced Edition for Blue Gene/P, V9.0
XL C/C++ Advanced Edition for Blue Gene/P Fix Pack 17 (October 2013 Update) for 9.0
April 2011 Update for XL C/C++ Advanced Edition for Blue Gene/P, V9.0
August 2011 Update for XL C/C++ Advanced Edition for Blue Gene/P, V9.0
April 2012 Update for XL C/C++ Advanced Edition for Blue Gene/P, V9.0
August 2012 Update for XL C/C++ Advanced Edition for Blue Gene/P, V9.0

APAR status

• Closed as program error.

Error description

• Compiling the following test case runs into error:
  
  
  > tc.c
  #include <stdio.h>
  #include <stdint.h>
  void main(){
     uint_least16_t  a[2][3] = { u"aa", u"bb" };
     printf("a=%d\n",sizeof(a));
  }
  > xlc tc.c -q64 -qutf
  "tc.c", line 4.37: 1506-196 (W) Initialization between types
  "unsigned short" and "unsigned short*" is not allowed.
  "tc.c", line 4.44: 1506-196 (W) Initialization between types
  "unsigned short" and "unsigned short*" is not allowed.
  

Local fix

• Do not use -q64
  

Problem summary

• Users may be affected when they use UTF Literals in 64-bit mode
  on AIX, or UTF literals in 32-bit mode on Linux platforms.
  
  The C compiler's support for UTF is tied to it's wchar support.
  UTF16 literals are always 2 bytes in size regardless of platform
  and Memory Model (32/64-bit).  But wchar types can be 2 bytes or
  4 bytes (4-bytes in 64-bit mode on AIX; and always 4 bytes on
  Linux).  The C compiler is treating the UTF literal (\u'a') as
  a wchar and in some cases (see above) thinks it is 4 bytes. When
  this string is assigned to a UTF16 type, the compiler thinks
  this is invalid.  Thus the error message occurs.
  

Problem conclusion

• To fix this issue, the compiler will untie the UTF literal
  support from wchar types. The compiler has a mechanism to
  determine if a symbol "could" be a character array.  In 64-bit
  mode on AIX, short[] would not be considered to be a possible
  Character array, since it's not a char type, and wchar's are 4
  bytes.  But arrays of (2 byte) UTF16 , which are Character
  types, were not considered a possible Character array.  And
  when one assigned a string literal or a character literal, an
  error was flagged.
  
  So the fix will allow the compiler to recognize that arrays of 2
  byte UTF could be a character array, on AIX in 64-bit mode, and
  on Linux in 32 or 64-bit mode.
  
  This fix will be applied to a future PTF.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

  IZ14503

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  XL C/C++ AE BG/

• Fixed component ID

  5799HJE00

Applicable component levels

• R900 PSN IZ14503

     UP06/09/13