Why can't a constant address be computed in a bitfield? - c

Question

I'm trying to implement a constant linked DMA descriptor list (in ROM) on an Silabs EFR32BG22, where the last descriptor links to another descriptor located in RAM.
I'm using arm-none-eabi-gcc 10.2 (Cortex M33).
I want to use the address of the descriptor in the .data section (desc3) in a constant initializer. However, this does not work when the descriptor struct is defined as a bitfield. desc1 fails to compile with the error initializer element is not computable at load time.
But as I understand it, all required information should be available at link time. And when I use the equivalent hack in desc2, my code compiles and works as expected.
Why can't the compiler figure out the initializer of the first struct, which should be a constant expression as well?
typedef struct {
uint32_t linkMode : 1;
uint32_t link : 1;
int32_t linkAddr : 30;
} DMA_Descriptor1_t;
typedef struct {
int32_t linkAddr;
} DMA_Descriptor2_t;
/* descriptor in RAM */
static DMA_Descriptor1_t desc3;
/* fails */
static const DMA_Descriptor1_t desc1 =
{
.linkMode = 0, // bit 0
.link = 1, // bit 1
.linkAddr = ((uint32_t) &desc3) // bits 31..2
};
/* works */
static const DMA_Descriptor2_t desc2 =
{
.linkAddr = ((uint32_t) &desc3 + (0x1uL << 1))
};

Answer 1

.linkAddr = ((uint32_t) &struct3)
This does not provide a constant expression for an initializer for a static object.
C 2018 6.7.9 4 says “All the expressions in an initializer for an object that has static or thread storage duration shall be constant expressions or string literals.”
C 2018 6.6 7 specifies what is permitted for constant expressions in initializers:
… Such a constant expression shall be, or evaluate to, one of the following:
— an arithmetic constant expression,
— a null pointer constant,
— an address constant, or
— an address constant for a complete object type plus or minus an integer constant expression.
((uint32_t) &struct3) is not an arithmetic constant expression because it does not only have operands that are “integer constants, floating constants, enumeration constants, character constants, sizeof expressions whose results are integer constants, and _Alignof expressions” (6.6 8), since struct3 is not any of those operands.
It is clearly not a null pointer constant.
&struct3 is an address constant (per 6.6 9, “a null pointer, a pointer to an lvalue designating an object of static storage duration, or a pointer to a function designator”), but (uint32_t) &struct3 is an address constant cast to another type, so it is not an address constant.
And it is not an address constant plus or minus an integer constant expression.
That is the rule-based reason why the initializer is not satisfactory according to the C standard. A practical reason is that address constants and address constants with displacements are implemented by “fix up” operations in the linker or program loader. When an object module is created, the compiler (or other creator) may be references to symbols (such as struct3) in it. Those references must occur in certain forms, such as whole words or as known fields in instruction encodings. After the linker or program loader determines the memory address of a symbol, it completes the references to symbols by filling in the locations where there were unresolved references to symbols. The software written for this only updates the specified forms of reference—it can patch a whole word with an address but cannot do arbitrary calculations, not even the masking and shifting needed to put part of the address into a bit-field.
When we look at .linkAddr = ((uint32_t) &desc3 + (0x1uL << 1)), we see the initializer is not a constant expression as defined above. However C 2018 6.6 10 says “An implementation may accept other forms of constant expressions,” and this expression is very similar to the fourth option above, an address constant plus an integer constant expression. This expression has an address constant converted to uint32_t. For a C implementation that uses a “flat” 32-bit address space with natural pointers, the conversion to uint32_t is functionally no-operation, just a type change, and then adding to it is equivalent to adding to a char *; it is a simple addition that is supported in the relocation fix-up operations.
In contrast, .linkAddr = ((uint32_t) &desc3) requires that initializer be converted to the 30-bit field of linkAddr. This is a different operation from addition, likely not supported by the relocation fix-up operations. Or, looking at the initialization of the structure as a whole, we see the goal is to initialize the entire 32 bits with the address with bits 0 and 1 set to 0 and 1, respectively. That could be done with a mask and an OR, but, again, the relocation fix-up operations do not support these operations.
Testing GCC on Compiler Explorer, we can see it accepts an addition with an address but does not accept an OR operation. We can reasonably conclude that GCC (for some platforms) accepts addresses (optionally cast to integers of the same width) with additions or subtractions but not with AND or OR operations.