[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604 --- Comment #6 from Richard Earnshaw --- For the record, the choice of unsigned for the default char type dates back to the original Arm architecture, which only had unsigned byte load instructions (and sign-extending values required two further instructions - a left shift followed by an arithmetic right shift). Even with the current architecture the A32 unsigned byte load instructions are more flexible than the signed byte load instructions.
[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604 Andrew Pinski changed: What|Removed |Added CC||mlwmohawk at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 101953 has been marked as a duplicate of this bug. ***
[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604 --- Comment #4 from Andrew Pinski --- (In reply to christopher békési from comment #3) > How come that it was decided to make the char on ARM unsigned whereas on x86 > platforms it's signed by default? I don't know, you are going to have to ask ARM that question. The ABI was defined by them. We are just users of it. There are other ABIs which also use unsigned as the plain char too (PowerPC); for that one you will have to ask IBM (they defined the original ABI).
[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604 --- Comment #3 from christopher békési --- (In reply to Andrew Pinski from comment #2) > In C, plain char can either be signed or unsigned; this is unlike int. > > Which of signed char or unsigned char has the same range, representation, > and behavior as “plain” char (C90 6.1.2.5, C90 6.2.1.1, C99 and C11 6.2.5, > C99 and C11 6.3.1.1). Indeed, I had completely missed that, I assumed the char was conforming to the same rules as the int when it comes to assuming its signed-ness. Explicitly specifying 'signed char' did yield the expected result. How come that it was decided to make the char on ARM unsigned whereas on x86 platforms it's signed by default? Thanks for the input, I'm sorry if I wasted anyone's time on this.
[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604 --- Comment #2 from Andrew Pinski --- In C, plain char can either be signed or unsigned; this is unlike int. Which of signed char or unsigned char has the same range, representation, and behavior as “plain” char (C90 6.1.2.5, C90 6.2.1.1, C99 and C11 6.2.5, C99 and C11 6.3.1.1).
[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|driver |target Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- char is unsigned on arm. This is documented in the ARM ABI as documented here: https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Characters-implementation.html#Characters-implementation
