Initialization of global pointers is accepted by clang++ but rejected by clang

[benshi001]

For the following code,

unsigned int * p = &(*(unsigned int *)0x400);

clang++ accepts it, but clang rejects with error

a.c:1:20: error: initializer element is not a compile-time constant
    1 | unsigned int * p = &(*(unsigned int *)0x400);
      |  

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Ben Shi (benshi001)

For the following code,

unsigned int * p = &(*(unsigned int *)0x400);

clang++ accepts it, but clang rejects with error

a.c:1:20: error: initializer element is not a compile-time constant
    1 | unsigned int * p = &(*(unsigned int *)0x400);
      |  

[benshi001]

This code looks strange but is used common in embedded devices, such as AVR.

#define PORT (*(unsigned int *)0x400)
unsigned int *p = &PORT;

[frederick-vs-ja]

I think such initialization should be valid.

&(*(unsigned int *)0x400) seems to be an address constant in C per C23/N3220 6.6/11, /12:

11. An address constant is a null pointer,¹¹⁸⁾ a pointer to an lvalue designating an object of static storage duration, or a pointer to a function designator; it shall be created explicitly using the unary & operator or an integer constant cast to pointer type, or implicitly using an expression of array or function type.
12. The array-subscript [] and member-access -> operator, the address & and indirection * unary operators, and pointer casts may be used in the creation of an address constant, but the value of an object shall not be accessed by use of these operators.¹¹⁹⁾

Note that 6.5.4.1/13:

The unary & operator yields the address of its operand. If the operand has type "type", the result has type "pointer to type". If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. [...]

(Such wording was added in C99 in order to resolve DR076, so I think it should also apply to C89 mode.)

[llvmbot]

@llvm/issue-subscribers-c

Author: Ben Shi (benshi001)

For the following code,

unsigned int * p = &(*(unsigned int *)0x400);

clang++ accepts it, but clang rejects with error

a.c:1:20: error: initializer element is not a compile-time constant
    1 | unsigned int * p = &(*(unsigned int *)0x400);
      |  

[AaronBallman]

More latitude is permitted for constant expressions in initializers. Such a constant expression shall
be, or evaluate to, one of the following:
— a named constant,

The macro does not expand to a named constant.

— a compound literal constant,

Nor a compound literal constant

— an arithmetic constant expression,

Nor an arithmetic constant expression

— a null pointer constant,

Nor a null pointer constant

— an address constant, or
— an address constant for a complete object type plus or minus an integer constant expression.

Nor an address constant:

An address constant is a null pointer,117) a pointer to an lvalue designating an object of static storage duration, or a pointer to a function designator; it shall be created explicitly using the unary & operator or an integer constant cast to pointer type, or implicitly using an expression of array or function type.

It's not an address constant because the pointer isn't pointing to either an object of static storage duration or function designator.

So I believe Clang is correct to reject this code, at least per the standard. I think the most practically portable way to write that code is:

#define PORT ((unsigned int *)0x400)
unsigned int *p = PORT;

https://godbolt.org/z/doYs1h4oc

It's not fully portable because it relies on this:

An implementation may accept other forms of constant expressions; however, it is implementationdefined whether they are an integer constant expression.

[benshi001]

https://www.godbolt.org/z/63oe59rs6

clang 20 accepts it ,but current trunk clang rejects it.

[benshi001]

cc @beakthoven, this issue would affect compiling of the arduino core libraries.

[AaronBallman]

https://www.godbolt.org/z/63oe59rs6

clang 20 accepts it ,but current trunk clang rejects it.

Good point! I hadn't realized this behavior changed recently, so thank you for pointing this out. Nothing jumps out at me in the releases notes as a cause, so we should probably bisect to see which commit changed the behavior. CC @shafik for help with bisection (though anyone is welcome to help out with that)

Temporarily adding the regression label just so it gets more attention as we work on the release. This may be an intentional change that didn't get release noted properly, it may be an unintentional change we want to address.