[PATCH] D85225: [Target][AArch64] Allow for char as int8_t in AArch64AsmParser.cpp

[Rainer Orth via Phabricator via llvm-commits]

ro added a comment.

In D85225#2224935 <https://reviews.llvm.org/D85225#2224935>, @MaskRay wrote:

>> The problem boils down to the fact that int8_t is plain char on Solaris: both the sparc and i386 psABIs have char as signed. However, with ...
>
> So, is -funsigned-char unsupported on Solaris?

Depends on your definition of "supported", I'd say. The option does exactly what it says. If you only apply it to your own code without interacting with system code (`libc` etc.), you should be ok.  However, as with other ABI-violating options, once you start using system code which by definition must follow the ABI, all bets are off.

Studio 12.6 cc(1) <https://docs.oracle.com/cd/E77782_01/html/E77803/cc-1.html#scrolltoc> puts it nicely for its equivalent `-xchar` option:

  The -xchar option changes the range of values for the type char only for code compiled with -xchar. This option does not change the range of values for type char in any system routine or header file. In particular, the value of CHAR_MAX and CHAR_MIN, as defined by limits.h, do not change when this option is specified. Therefore, CHAR_MAX and CHAR_MIN no longer represent the range of values encodable in a plain char.
  
  If you use -xchar, be particularly careful when you compare a char against a predefined system macro because the value in the macro may be signed. This is most common for any routine that returns an error code which is accessed through a macro. Error codes are typically negative values so when you compare a char against the value from such a macro, the result is always false. A negative number can never be equal to any value of an unsigned type.
  
  It is strongly recommended that you never use -xchar to compile routines for any interface exported through a library. The Oracle Solaris ABI specifies type char as signed, and system libraries behave accordingly. The effect of making char unsigned has not been extensively tested with system libraries. Instead of using this option, modify your code that it does not depend on whether type char is signed or unsigned. The sign of type char varies among compilers and operating systems.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85225/new/

https://reviews.llvm.org/D85225