msp430-gcc 4.6.3 signed overflow questions

[Rickta59 589]

I've been working on some C++ template based classes and ran into a snag. Turns out when I reduced the code down to a straight 'C' implementation I still have the same problem.

 

The code below has issues with the int8_t data type. If you start at 126 and increment it should roll over to a negative number but it doesn't. This problem seems to appear when i use -Os ( which is my normal mode of operation ) and does go away if you back off and use -O1. I'm not sure if Peter is still following compiler development. If nothing else it would interesting if others try this with their version of the compiler. I'm using the linux version that ships with Energia:

gcc version 4.6.3 20120301 (mspgcc LTS 20120406 unpatched) (MSPGCC 20120406 (With patches: sf3540953 sf3559978)) 

Adding volatile to just the int8_t declaration will get rid of the problem.

 

If you use msp430-gcc you might try this code and post your results.

 

Thanks,

 

-rick

 

hosted on github: https://gist.github.com/RickKimball/4957969

 

[kff2 22]

The results that you are seeing are not necessarily wrong. Signed integer overflow is not well defined in C or C++. It looks like gcc wraps around overflown integers in some cases and saturates them in others. Inconsistent, but not really a bug either.

 

See 

 

http://thiemonagel.de/2010/01/signed-integer-overflow/

 

You can try the -fwrapv option mentioned in the article.

[roadrunner84 466]

Personally, I barely ever use signed scalars, and when I do, I do not assume wrap around from MAX to MIN. I cannot think of a case in which I'd need this behaviour either.

Nonetheless it's weird that 125 and 127 work, but 126 doesn't. Setting variables to volatile kills efficiency too, maybe you could even better step down a level of optimization?

[Rickta59 589]

You can try the -fwrapv option mentioned in the article.

Thanks! This does indeed fix the problem.

[Rickta59 589]

Personally, I barely ever use signed scalars, and when I do, I do not assume wrap around from MAX to MIN. I cannot think of a case in which I'd need this behaviour either.

I was looking for a quick test for a print format routine and came up with that. I see now that it is undefined behavior and can't be relied on. However, with that said, I'm going to provide code to other people who will surely abuse it. At least, I have an answer to their future questions.