gcc ARM bug [solved]

[MattOwnby]

I am sure I am not the first person to stumble across this [apparent] bug in gcc, but I googled around a bit to find previous discussion about it to no avail. Basically, if you have an unsigned int and you add a char to it, the result is corrupt. Perhaps I am missing something and this is not a bug, but it sure looks like one to me. If I am wrong, I'd love to hear about it. (see next post for solution)

Here is the simple code to prove the bug:

Code: Select all

#include <stdio.h>

int main(int argc, char **argv)
{
        unsigned int PC = 0xfad5;
        char btemp = -51;

        PC = PC + btemp;

        printf("PC is %x\n", PC);

        return 0;
}

Correct result is 0xFAA2 for PC, on my pi it is 0xFBA2.

Adding a signed int works fine. It's just the signed char that is failing.

ALso confirmed this on 4.7.2

version info:

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-12+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-12+rpi1)

[OtherCrashOverride]

Its not a bug. It just means that the default char type for the platform is unsigned so the '-51' gets converted and the math is correct.

[MattOwnby]

Ah ha!! Yes, I see now what you are saying. If I explicitly change it from "char" to "signed char" then it all works as expected.

That is so weird, I would've thought that "char" would imply "signed char" in the C standard and that all platforms must conform.

Anyway, thanks for the tip! You've saved me!

[rurwin]

The C Programming Language, section A4.2 states thus:

Objects declared as characters (char) are large enough to store any member of the execution character set. If a genuine character from that set is stored in a char object, its value is equivalent to the integer code for the character, and is non-negative. Other values may be stored into a char variable, but the available range of values, and especially whether the value is signed or unsigned, is implementation-dependent.

[plugwash]

BTW you can also use -fsigned-char and -funsigned-char to override the platform default for char signedness.