GCC with C++20 compound volatile warning
MaJerle opened this issue · comments
With GCC 10 and C++20, |=, &=, ++, -- operands on volatile keyword result in a warning for deprecated volatile keyword with compound statements. This therefore applies to all variables working with silicon registers.
This code produces following warnin:
compound assignment with 'volatile'-qualified left operand is deprecated [-Wvolatile]
While this code doesn't:
SCB->CCR = SCB->CCR | (uint32_t)SCB_CCR_IC_Msk; /* enable I-Cache */
Hi @MaJerle,
Please note that CMSIS does not claim any sort of C++ support, yet. The code you are facing with conforms to C99. Please try to include this code as extern "C". This should allow your C++20 application to interface with CMSIS, successfully.
Especially the C code for cache maintenance is tricky and unfortunately not fully portable. It relies on the Compiler not using stack for instance. Such behaviour cannot be enforced in today's Compilers. If the Compiler decides to store intermediate values on stack instead of keeping them in registers the code will fail. This may easily happen on low optimisation levels.
So far, I don't have a proper solution for this.
Cheers,
Jonatan
Adding extern "C" is no solving the problem when the error comes from header and not from source.
For people using GCC you can disable individual warnings with -Wno-volatile but this will mute the warning for whole file.
You might mute it selectively with
#pragma GCC diagnostic ignored "-Wvolatile"
#include "CMSIS_related.h"
#pragma GCC pop@JonatanAntoni the rationale behind this C++ warning is really interesting. Because SCB->CCR is volatile it WILL be read before operation and write back. The proposed change only explicits this read. I see absolutely no reason the compiler to behave differently between the two. There is also absolutely no reason for the compiler to put the variable on stack in such a line.
Here I tested with GCC and -o0 optimization and indeed in this simple case it's same output:
https://godbolt.org/z/jsWdMnj3h
I mean if the code behaves wrong with the proposed change, it means it could also behave wrong with current implementation. Compiler offers no guarantee (this is exactly why tis rationale was introduced).
Luckily for you, C++ standard might go back from their initial choice because header exactly like yours (see https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2327r0.pdf).