[BUG] FreeRTOS v10.5.1 and IAR compiler v9.32.1 causes Remark[Pa091]

[rhobison]

Compilation with IAR EWARM v9.32.1 causes Remark[Pa091] to be issued.

[ 83%] Building C object rtos_freertos/v10.5.1/Source/CMakeFiles/freertos_kernel.dir/timers.c.o

                  pxTimer->ucStatus &= ( ( uint8_t ) ~tmrSTATUS_IS_AUTORELOAD );
                                                     ^
"rtos_freertos\v10.5.1\Source\timers.c",465  Remark[Pa091]:
          operator operates on value promoted to int (with possibly unexpected
          result)

              pxTimer->ucStatus &= ( ( uint8_t ) ~tmrSTATUS_IS_ACTIVE );
                                                 ^
"rtos_freertos\v10.5.1\Source\timers.c",559  Remark[Pa091]:
          operator operates on value promoted to int (with possibly unexpected
          result)

                                  pxTimer->ucStatus &= ( ( uint8_t ) ~tmrSTATUS_IS_ACTIVE );
                                                                     ^
"rtos_freertos\v10.5.1\Source\timers.c",838  Remark[Pa091]:
          operator operates on value promoted to int (with possibly unexpected
          result)

                          pxTimer->ucStatus &= ( ( uint8_t ) ~tmrSTATUS_IS_ACTIVE );
                                                             ^
"rtos_freertos\v10.5.1\Source\timers.c",855  Remark[Pa091]: 
          operator operates on value promoted to int (with possibly unexpected
          result)

                                  pxTimer->ucStatus &= ( ( uint8_t ) ~tmrSTATUS_IS_ACTIVE );
                                                                     ^
"rtos_freertos\v10.5.1\Source\timers.c",885  Remark[Pa091]:
          operator operates on value promoted to int (with possibly unexpected
          result)

Removing the cast (uint8_t) from the following macros fix the Remarks:

/* Bit definitions used in the ucStatus member of a timer structure. */
    #define tmrSTATUS_IS_ACTIVE                  ( ( uint8_t ) 0x01 )
    #define tmrSTATUS_IS_STATICALLY_ALLOCATED    ( ( uint8_t ) 0x02 )
    #define tmrSTATUS_IS_AUTORELOAD              ( ( uint8_t ) 0x04 ) 

Target

• Instruction Set Architecture: Arm Cortex-m0
• Toolchain and version: IAR EWARM v9.32.1

Host

• Host OS: Windows
• Version: Win10 21H2

[Skptak]

Hey @rhobison, thanks for bringing this to our attention!
Looking into this it seems like this issue is caused by the uint8_t macro value being raised to an int before being inverted. According to this forum post, a possible fix might be changing these lines to instead perform this operation:
pxTimer->ucStatus &= ( ~( uint8_t ) tmrSTATUS_IS_ACTIVE );
As I don't know what demo or project you are running, would you mind giving that a try and letting me know if that fixes your issue?
If you can't I can look into trying it myself as well.

[rhobison]

Hi Skptak,

The change you suggested did not fix the Remark. As you said, the issue is caused by the uint8_t being raised to an int.
In your proposed solution, we still have the same issue.
If you expand the macro tmrSTATUS_IS_ACTIVE, you will see that we already have that cast:

pxTimer->ucStatus &= ( ( uint8_t ) ~( ( uint8_t ) 0x01 ) );

The forum post you linked suggests casting it to an unsigned int (unsigned == unsigned int). That, indeed, fixes the issue.
In summary, the expression after ~ must not be an unsigned char/uint8_t. Some of the options:

• Remove ( uint8_t ) from the macro itself (the default type for integral types is int): #define tmrSTATUS_IS_ACTIVE ( 0x01 )
• Explicitly cast to ( uint32_t ) in the macro itself: #define tmrSTATUS_IS_ACTIVE ( ( uint32_t )0x01 )
• Add an extra cast ( uint32_t ) after ~ on all usages of that macro: pxTimer->ucStatus &= ( ( uint8_t ) ~( uint32_t )tmrSTATUS_IS_ACTIVE );
• ?

Let me know if you need anything else and thank you for looking at this issue.

[RichardBarry]

What about removing the uint8_t cast in the macro, and instead adding a 'U' to the 0x01 (so it reads 0x01U).

[rhobison]

Yeah, that is also possible, the number is now ‘unsigned int‘, instead of the default ’int’, which is more appropriate for a bit mask, indeed.

[aggarg]

Thank you for reporting this. It has been fixed in this PR - #763