Из стандарта языка:
C++ Standard ISO/IEC 14882:2003
2.13.1 Integer literals
The type of an integer literal depends on its form, value, and suffix. If it is decimal and has no suffix, it has
the first of these types in which its value can be represented: int, long int; if the value cannot be represented
as a long int, the behavior is undefined. If it is octal or hexadecimal and has no suffix, it has the
first of these types in which its value can be represented: int, unsigned int, long int, unsigned
long int. If it is suffixed by u or U, its type is the first of these types in which its value can be represented:
unsigned int, unsigned long int. If it is suffixed by l or L, its type is the first of these
types in which its value can be represented: long int, unsigned long int. If it is suffixed by ul,
lu, uL, Lu, Ul, lU, UL, or LU, its type is unsigned long int.

т.е. это указание что константа 1 имеет тип unsigned long int.
В данном конкретном случае это не важно, тип int у IAR для ARM и так 32-битный, а результат сдвига влево не зависит от знаковости операнда, но случаи - они разные бывают

Да? а как тогда компилятору трактовать сдвиг абстрактной 1 влево на 31, например:
unsigned long value = 1<<31;
Вменяемый компилятор должен предупредить, что пытаетесь присвоить получившиеся знаковое значение беззнаковой переменной,
если не скажете про беззаковость:
unsigned long value = 1UL<<31;

Это да, про сдвиг на 31 я что-то сразу не сообразил.
Впрочем, по стандарту это не ошибка (int может быть преобразован в unsigned long), а только повод выдать предупреждение.
Что IAR и делает:
Warning[Pe068]: integer conversion resulted in a change of sign

А вот на такое уже не предупреждает, ибо не в состоянии отследить сомнительные значения:
extern int xxx;
unsigned long value = xxx+(1<<31);

Там не нужно было изучать язык ассемблера и документацию на конкретный ассемблер? Знание приходило свыше само?