The test case looks like this:

enum e

x;
if (x < 2u) ...

The enumeration values would fit in either a signed char or unsigned char. Either would be a reasonable choice to use as the underlying integer type of the enum type. The choice is made by the compiler according to the rules of the ABI. For the ARM compiler, the choice depends partially on whether the program is compiled in strict ANSI mode and the value of the --enum_type command-line option. (Note that in C, the 'u' suffix on those enumeration constant initializers doesn't impact the type of either the enumeration constants or the underlying type of the enum.) In this case, the compiler is in strict ANSI mode and --enum_type=packed mode. The underlying type chosen by the parser has changed between 20.2.1.LTS and 20.2.2.LTS. This behavior change is deliberate, and due to the fix for EXT_EP-9853. 20.2.1.LTS chose "plain char", which defaults to "unsigned char", and 20.2.2.LTS chooses "signed char," the type intended by the implementer.

The user's code compares a value of the enum type to an unsigned integer that isn't of enum type. 20.2.1.LTS would not have emitted a remark, but 20.2.2.LTS will now emit the remark "comparison between signed and unsigned operands." Remarks do not appear by default unless the user enables them with the --issue_remarks command-line option.

Avoid using --issue_remarks or use the -pds2142 option to suppress this particular remark.

Alternately, you can force the compiler to prefer "unsigned char" over "signed char" by adding a dummy enumeration constant with the value UCHAR_MAX:

#include <limits.h>
enum e

;