Skip to main content
waclawek.jan
Super User
January 14, 2026
Question

'register' specifier in Cube/LL

  • January 14, 2026
  • 3 replies
  • 350 views

I have a bunch of following warnings:

c:/programs/ARMtools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32F1xxxx/STM32F1xx_HAL_Driver/Inc/stm32f1xx_ll_gpio.h: In function 'void LL_GPIO_SetPinMode(GPIO_TypeDef*, uint32_t, uint32_t)':
c:/programs/ARMtools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32F1xxxx/STM32F1xx_HAL_Driver/Inc/stm32f1xx_ll_gpio.h:343:22: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
 343 | register uint32_t *pReg = (uint32_t *)((uint32_t)((uint32_t)(&GPIOx->CRL) + (Pin >> 24)));
 |

in several LL headers.

Can this please be fixed in some suitable way? One way to do that might be to replace the 'register' specifier by a macro, which would be defined based on the __cplusplus  standard preprocessor macro and its value. A simple version would be to add

#if __cplusplus >= 201703L
#define register
#endif

to each header where this occurs, but I am not a C++/build-environment specialist so don't know whether this may have some unwanted effect I am not aware off.

Thanks,

JW

3 replies

Andrew Neil
Super User
January 14, 2026

Same Issue recently:

HAL functions using archaic terms - why? 

(the "archaic term" is the register specifier)

 

PS:

and from 2018:

Is the "register" storage class specifier necessary in STM32 LL interfaces?

TL;DR: No.

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
T_Hamdi
ST Employee
January 15, 2026

Hello @waclawek.jan ,

Please refer to the package available on GitHub. it has been updated and this item has been removed from the header file: stm32f1xx_ll_gpio.h 

Please download the latest version of the package from the GitHub page.

thank you!

Hamdi

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Hamdi Teyeb"
Andrew Neil
Super User
January 15, 2026

Is it just the F1 that's been updated?

The other linked threads refer to U0 and L4

Presumably (all?) others are similarly affected?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
T_Hamdi
ST Employee
January 15, 2026

hello @Andrew Neil 

Yes, all of them have been updated, not just the F1.
The same change has been applied to the other affected series.

thank you!

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Hamdi Teyeb"
waclawek.jan
Super User
January 15, 2026

Hi @T_Hamdi ,

thanks, that would solve it for this particular header file.

But what about other headers, e.g. https://github.com/STMicroelectronics/stm32f1xx-hal-driver/blob/a433ed968f1812eff2de76288af48aab2e369e9f/Inc/stm32f1xx_ll_rtc.h#L553 ?

JW

T_Hamdi
ST Employee
January 15, 2026

Hello @waclawek.jan 

Thank you for bringing this issue to our attention.

I reported this internally. Internal ticket number: 225259 (This is an internal tracking number and is not accessible or usable by customers).

Best regards,

Hamdi

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Hamdi Teyeb"