[clang] compound literals within local structs should not require constant initialization

Compiler Explorer

// [clang] error: initializer element is not a compile-time constant
// [ gcc ] ok

/* const */ size_t i;

         static_assert (!! sizeof ((size_t) {i}));    // OK
struct { static_assert (!! sizeof ((size_t) {i})); }; // KO

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Sofian Touhami (swordkill)

**Hi Humans,**

> Last year I shared an issue related to VLA and Blocks (extension) :
#63412

I come back for one more embarrassing, related either to C99 compound literals, or C11 _Generics or _Static_assert.

Here is a reproduction :
https://godbolt.org/z/9dTa4YP4n

The purpose is to be able to use static assertion within an expression.

/*
** Using -std=c23.
**
** The trick is that static_assert is garanteed by the standard 
** to not produce anything :
** 
** - https://en.cppreference.com/w/c/language/_Static_assert
**
** """Otherwise, 
**      if expression does not equal zero, nothing happens; 
**      no code is emitted.
** """
**/
#define static_expr(e) \
    ( !! sizeof (struct {static_assert (e); char c;}) )

#define is_same(e1, e2)                 \
    _Generic (&(typeof_unqual (e1)) {}  \
        , typeof_unqual (e2) * : true   \
        , default              : false  \
    )

The issue

/*
** It's OK.
**/
typeof        ((size_t) {i}) witness_one;
typeof_unqual ((size_t) {i}) witness_two;

/*
** It's OK.
**/
is_same (witness_one, (size_t) {i});
is_same (witness_two, (size_t) {i});

/*
** It's OK.
**/
static_assert (is_same (witness_one, (size_t) {i}));

/*
** It's KO.
** [clang] error: initializer element is not a compile-time constant
** [gcc  ] everything is good buddy
**/
static_expr (is_same (witness_one, (size_t) {i}));

[shafik]

CC @AaronBallman

[AaronBallman]

A reduced equivalent reproducer is:

void foo() {
  int i = 1;    

  struct {
    int array[sizeof((int){i})];
  } s;
}

https://godbolt.org/z/66E96oqq4

As pointed out above, the struct matters: https://godbolt.org/z/4h45zsxcd (note the lack of a -Wvla diagnostic, so it's not that we're rejecting because we introduce a VLA into a structure or something along those lines). But also, whether it's declared at file scope or not also matters: https://godbolt.org/z/qc1KfYzGM

My intuition is that this is a Clang bug and we should accept the original code, but I've not yet investigated what the standard says.

[AaronBallman]

C23 6.5.3.6p3: All the constraints for initializer lists in 6.7.11 also apply to compound literals.
C23 6.7.11p5: All the expressions in an initializer for an object that has static or thread storage duration or is declared with the constexpr storage-class specifier shall be constant expressions or string literals.

So we're fine there (nothing else in 6.7.11's constraints really applies). I don't see any further constraints in 6.5.3.6 that would justify Clang's behavior, so confirming the issue.

[llvmbot]

@llvm/issue-subscribers-c

Author: Sofian Touhami (SwordKill)

**Hi Humans,**

> Last year I shared an issue related to VLA and Blocks (extension) :
#63412

I come back for one more embarrassing, related either to C99 compound literals, or C11 _Generics or _Static_assert.

Here is a reproduction :
https://godbolt.org/z/9dTa4YP4n

The purpose is to be able to use static assertion within an expression.

/*
** Using -std=c23.
**
** The trick is that static_assert is garanteed by the standard 
** to not produce anything :
** 
** - https://en.cppreference.com/w/c/language/_Static_assert
**
** """Otherwise, 
**      if expression does not equal zero, nothing happens; 
**      no code is emitted.
** """
**/
#define static_expr(e) \
    ( !! sizeof (struct {static_assert (e); char c;}) )

#define is_same(e1, e2)                 \
    _Generic (&(typeof_unqual (e1)) {}  \
        , typeof_unqual (e2) * : true   \
        , default              : false  \
    )

The issue

/*
** It's OK.
**/
typeof        ((size_t) {i}) witness_one;
typeof_unqual ((size_t) {i}) witness_two;

/*
** It's OK.
**/
is_same (witness_one, (size_t) {i});
is_same (witness_two, (size_t) {i});

/*
** It's OK.
**/
static_assert (is_same (witness_one, (size_t) {i}));

/*
** It's KO.
** [clang] error: initializer element is not a compile-time constant
** [ gcc ] everything is good buddy
**/
static_expr (is_same (witness_one, (size_t) {i}));

[zygoloid]

I don't have C23 to hand, but in the draft I do have, I found this:

6.5.3.6/3: If the compound literal occurs outside the body of a function, the object has static storage duration; otherwise, it has automatic storage duration associated with the enclosing block.

but conversely:

6.2.4/6: If an initialization is specified for the object, it is performed each time the declaration or compound literal is reached in the execution of the block; otherwise, the value becomes indeterminate each time the declaration is reached.

... which together seem to mean that the compound literal isn't required to have a constant initializer in this case, but also that its initializer is never actually evaluated at runtime either. Which is weird, but OK I guess, given that presumably it can only occur in things like sizeof or typeof anyway.

That behavior is also inconsistent:

int n;

void f() {
  struct A {
    // OK.
    int array[sizeof((int){n})];
  };
}

struct B {
  // Ill-formed.
  int array[sizeof((int){n})];
};

... but accepting A and rejecting B is what GCC does, and what the C standard seems to ask for. shrug

[AaronBallman]

How dare you change my concise title? You're like those recent anime that spoil the entire story in the title! Shame on you!

Please familiarize yourself with our Code of Conduct. For what it's worth, we frequently reword issue titles (and summaries) so that it's easier for community members to understand the issue without having to read through as many comments.

Also, did you guys know that the C23 specification for the auto keyword is ambiguous? I mean, clearly it already behaves differently between Clang and GCC, with the GCC version being more restricted.

This is unrelated to the original issue; you should file a separate issue if you think Clang has a bug, otherwise it's too easy for things to get lost in discussion.

Well, this is off-topic,

It is. :-)