Problems with integer promotion in C - c

Question

I'm developing a C code for an embedded application for ARM processor (LPC54628) using Keil software. There's a strange behavior that I am unable to resolve. I tried running this on the software simulator as well as on the microcontroller and the behavior is the same. The problem is with the execution of the second 'else if' condition.
Working code:
uint8_t a; uint8_t b ; uint8_t temp1; uint8_t temp2; uint8_t c;
a = 0x1; b = 0x80; temp1 = 0; temp2 = 0; c = 10U;
temp1 = (b << 1); // after execution, temp1 is 0x00
temp2 = (b >> 7); // after execution, temp2 is 0x01
__NOP();
temp1 = ((b << 1) | (b >> 7)); // after execution, temp1 is 0x00 | 0x01 = 0x01
if (a == b) { }
else if ( a == ((b >> 1) | (b << 7)) ) {c += 1; }
else if ( a == temp1 ) {c -= 1; } // this 'else if' executes since a= 0x01 and temp1 = 0x01
else if ( a == ((b >> 2) | (b << 6)) ) {c += 2; }
else if ( a == ((b << 2) | (b >> 6)) ) {c -= 2; }
else if ( a == ((b >> 3) | (b << 5)) ) {c += 3; }
else if ( a == ((b << 3) | (b >> 5)) ) {c -= 3; }
However, the 'else if' that worked in the code above fails to execute in the following code. Note that the only change I have done is to replace temp1 with the actual expression inside the 'else if' condition. No other change.
Non-working code:
a = 0x1; b = 0x80; temp1 = 0; temp2 = 0; c = 10U;
temp1 = (b << 1); // after execution, temp1 is 0x00
temp2 = (b >> 7); // after execution, temp2 is 0x01
__NOP();
temp1 = ((b << 1) | (b >> 7)); // after execution, temp1 is 0x00 | 0x01 = 0x01
if (a == b) { }
else if ( a == ((b >> 1) | (b << 7)) ) {c += 1; }
else if ( a == ((b << 1) | (b >> 7)) ) {c -= 1; } // this 'else if' DOES NOT execute.
else if ( a == ((b >> 2) | (b << 6)) ) {c += 2; }
else if ( a == ((b << 2) | (b >> 6)) ) {c -= 2; }
else if ( a == ((b >> 3) | (b << 5)) ) {c += 3; }
else if ( a == ((b << 3) | (b >> 5)) ) {c -= 3; }
Can you point out what I am doing wrong?

Answer 1

Integer promotion is annoying. You're fundamentally doing:
else if ( (int) a == (((int)(b << 1)) | ((int)(b >> 7))) ) {
c -= 1;
}
Which means that you're testing if 0x01 == 0x101, which it doesn't.
When you do something like:
uint8_t x = 3;
uint8_t y = x + 4;
You're really doing something like:
uint8_t x = 3;
uint8_t y = (uint8_t)((int) x) + 4)

Answer 2

In the expression ((b << 1) | (b >> 7)), the value b is first promoted to type int because its type is smaller than int. So this expression ends up being:
((0x80 << 1) | (0x80 >> 7)) == (0x100 | 0x1) == 0x101
When you assign this value to temp1, it is converted to a value that fits and you're left with 0x1. When you instead compare the result of this expression directly against a, you're comparing the value 0x1 with 0x101.
If you want the result of this expression to be 8 bit, you need to cast it to uint8_t to truncate the higher bits.
if (a == b) { }
else if ( a == (uint8_t)((b >> 1) | (b << 7)) ) {c += 1; }
else if ( a == (uint8_t)((b << 1) | (b >> 7)) ) {c -= 1; }
else if ( a == (uint8_t)((b >> 2) | (b << 6)) ) {c += 2; }
else if ( a == (uint8_t)((b << 2) | (b >> 6)) ) {c -= 2; }
else if ( a == (uint8_t)((b >> 3) | (b << 5)) ) {c += 3; }
else if ( a == (uint8_t)((b << 3) | (b >> 5)) ) {c -= 3; }

Answer 3

C compilers did NOT used to do this, I do not know exactly when it changed.
unsigned int fun0 ( unsigned char a, unsigned char b )
{
return((a<<1)|(b>>1));
}
unsigned int fun1 ( unsigned char a, unsigned char b )
{
return(unsigned char)((a<<1)|(b>>1));
}
00000000 <fun0>:
0: e1a010a1 lsr r1, r1, #1
4: e1810080 orr r0, r1, r0, lsl #1
8: e12fff1e bx lr
0000000c <fun1>:
c: e1a010a1 lsr r1, r1, #1
10: e1810080 orr r0, r1, r0, lsl #1
14: e20000ff and r0, r0, #255 ; 0xff
18: e12fff1e bx lr
The first one the operation is on 8 bit values before it is combined to be returned. The second is clipped.
I specifically had a day of year problem many many years ago now, the bug would appear late in the year (just so happened to be day 256) and fixed itself January first... day = (high_byte<<8)|(low_byte); (fixed with ...((unsigned int)high_byte)<<8...)
unsigned int fun ( unsigned char a, unsigned char b )
{
return((a<<8)|b);
}
00000000 <fun>:
0: e1810400 orr r0, r1, r0, lsl #8
4: e12fff1e bx lr
Would not have broken today...at least with gcc 10.x.x...I also want to say at some point it was implementation defined, but seems that from many of the various quotes on the net it has been this way since C99...
Note disassembly is your friend...But then always understand that sometimes it is implementation defined (does not seem so in this case) and that just because your compiler did it one way does not mean that is the standard and is true for all compilers. (you are using Kiel I am using gnu for example).
Folks run into this a lot with floating point
float fun0 ( float a, float b )
{
return(a*(b+2.0));
}
float fun1 ( float a, float b )
{
return(a*(b+2.0F));
}
00000000 <fun0>:
0: e92d4070 push {r4, r5, r6, lr}
4: e1a06000 mov r6, r0
8: e1a00001 mov r0, r1
c: ebfffffe bl 0 <__aeabi_f2d>
10: e3a02000 mov r2, #0
14: e3a03101 mov r3, #1073741824 ; 0x40000000
18: ebfffffe bl 0 <__aeabi_dadd>
1c: e1a04000 mov r4, r0
20: e1a00006 mov r0, r6
24: e1a05001 mov r5, r1
28: ebfffffe bl 0 <__aeabi_f2d>
2c: e1a02000 mov r2, r0
30: e1a03001 mov r3, r1
34: e1a00004 mov r0, r4
38: e1a01005 mov r1, r5
3c: ebfffffe bl 0 <__aeabi_dmul>
40: ebfffffe bl 0 <__aeabi_d2f>
44: e8bd4070 pop {r4, r5, r6, lr}
48: e12fff1e bx lr
0000004c <fun1>:
4c: e92d4010 push {r4, lr}
50: e1a04000 mov r4, r0
54: e1a00001 mov r0, r1
58: e3a01101 mov r1, #1073741824 ; 0x40000000
5c: ebfffffe bl 0 <__aeabi_fadd>
60: e1a01004 mov r1, r4
64: ebfffffe bl 0 <__aeabi_fmul>
68: e8bd4010 pop {r4, lr}
6c: e12fff1e bx lr
2.0 is a double in the eyes of the compiler but 2.0F is single. And a double plus a single gets promoted to a double operation. Not an integer promotion but constants have an implied type (integer or floating point) and that plays into promotion.