"static assertion expression is not an integral constant expression" when compiling glib with clang 15

[intractabilis]

$ clang --version
clang version 15.0.0 (https://github.com/llvm/llvm-project.git 1c73596d345481de957e5ccc0bedf1fb9d9f643a)
Target: x86_64-unknown-linux-gnu
Thread model: posix

When compiling glib (https://gitlab.gnome.org/GNOME/glib), Clang 15 issues an error "static assertion expression is not an integral constant expression".

Configuration step:

meson --buildtype=release . ../glib

Error message:

[352/1350] Compiling C object gio/gio-launch-desktop.p/gio-launch-desktop.c.o
FAILED: gio/gio-launch-desktop.p/gio-launch-desktop.c.o
clang -Igio/gio-launch-desktop.p -Igio -I../glib/gio -Iglib -I../glib/glib -fcolor-diagnostics -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -std=gnu99 -O3 -D_GNU_SOURCE -fno-strict-aliasing -DG_DISABLE_CAST_CHECKS -Wimplicit-fallthrough -Wmisleading-indentation -Wunused -Wno-unused-parameter -Wno-cast-function-type -Wno-pedantic -Wno-format-zero-length -Wno-variadic-macros -Werror=format=2 -Werror=init-self -Werror=missing-include-dirs -Werror=pointer-arith -Werror=unused-result -Wstrict-prototypes -Wno-bad-function-cast -Werror=declaration-after-statement -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=pointer-sign '-DG_LOG_DOMAIN="GLib-GIO"' -DGIO_COMPILATION '-DGIO_LAUNCH_DESKTOP="/usr/local/libexec/gio-launch-desktop"' '-DGIO_MODULE_DIR="/usr/local/lib/gio/modules"' '-DLOCALSTATEDIR="/var/local"' -fvisibility=hidden -MD -MQ gio/gio-launch-desktop.p/gio-launch-desktop.c.o -MF gio/gio-launch-desktop.p/gio-launch-desktop.c.o.d -o gio/gio-launch-desktop.p/gio-launch-desktop.c.o -c ../glib/gio/gio-launch-desktop.c
../glib/gio/gio-launch-desktop.c:124:20: error: static assertion expression is not an integral constant expression
  G_STATIC_ASSERT (LOG_EMERG == 0 && "Linux ABI defines LOG_EMERG");
  ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/sys/syslog.h:51:19: note: expanded from macro 'LOG_EMERG'
#define LOG_EMERG       0       /* system is unusable */
                        ^
../glib/glib/gmacros.h:824:47: note: expanded from macro 'G_STATIC_ASSERT'
#define G_STATIC_ASSERT(expr) _Static_assert (expr, "Expression evaluates to false")
                                              ^~~~
../glib/gio/gio-launch-desktop.c:125:20: error: static assertion expression is not an integral constant expression
  G_STATIC_ASSERT (LOG_DEBUG == 7 && "Linux ABI defines LOG_DEBUG");
  ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/sys/syslog.h:58:19: note: expanded from macro 'LOG_DEBUG'
#define LOG_DEBUG       7       /* debug-level messages */
                        ^
../glib/glib/gmacros.h:824:47: note: expanded from macro 'G_STATIC_ASSERT'
#define G_STATIC_ASSERT(expr) _Static_assert (expr, "Expression evaluates to false")
                                              ^~~~
2 errors generated.

Expressions like 0 == 0 and 7 == 7 are integer constant expressions. I am not sure what Clang doesn't like. Another strange thing is _Static_assert is technically from C11, but as illustrated by the provided error message, glib passes std=gnu99.

[tbaederr]

The && "string" is the problem: https://godbolt.org/z/o6nEG7dz5

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[msebor]

The first operand of _Static_assert must be an integer constant expression, and

an arithmetic constant expression shall have arithmetic type and shall only have operands that are integer constants, floating constants, enumeration constants, character constants, sizeof expressions whose results are integer constants, and _Alignof expressions.

In LOG_DEBUG == 7 && "Linux ABI defines LOG_DEBUG" the string literal is not such a constant and so neither is the whole && expression. (GCC accepts the code but issues a -Wpedantic warning for it when it's enabled; ICC rejects it with an error.)

[jyknight]

Sounds like not a bug, closing as such.

[intractabilis]

The first operand of _Static_assert must be an integer constant expression, and

an arithmetic constant expression shall have arithmetic type and shall only have operands that are integer constants, floating constants, enumeration constants, character constants, sizeof expressions whose results are integer constants, and _Alignof expressions.

In LOG_DEBUG == 7 && "Linux ABI defines LOG_DEBUG" the string literal is not such a constant and so neither is the whole && expression. (GCC accepts the code but issues a -Wpedantic warning for it when it's enabled; ICC rejects it with an error.)

@msebor This is true for C11, but you are compiling with -std=gnu99, i.e. "C99 with GNU extensions".

[intractabilis]

Does it mean Clang team doesn't want to support GNU extensions when compiling in "C99 with GNU extensions" mode?

[msebor]

GCC documents its extensions in the C Extensions section of the manual, and Clang in the Differences between various standard modes. As far as I can see, neither discusses this extension. In GCC's case it might be an omission worth fixing, or it might intentionally be undocumented to keep users from relying on it. In Clang's, I'd take that to mean that it's not meant to be supported. No GCC-compatible compiler matches GCC behavior in every respect, nor can it realistically be expected to. But in this case it would seem reasonable to request it in order to support the condition && "description" idiom that's common in runtime assertions.

[intractabilis]

Thank you for exploring this. You are right, I couldn't find _Static_assert in the extensions' documentation at all. It seems like GCC team assumed since it is a part of C11 now, they don't have to mention it as an extension to C99.

[msebor]

To be clear, the extension I was referring to is treating equality expressions involving string literals as constant integer expressions. The first argument to _Static_assert is just one context where constant integer expressions are required.

That said, since Clang treats the same expression as an integer constant is most other contexts (see the test case below), I think the fact that it rejects it in _Static_assert should be considered a bug. With that let me reopen this report to let someone more familiar with the C front end than myself take another look at it.

$ cat a.c && clang -S -Wall -Wpedantic a.c
typedef int A[1 && ""];         // treated as a constant integer expression
enum { e = 1 && "" };           // same
_Static_assert (1 && "", "");   // not treated as a constant integer expression

void f (void) {
  switch (1) case 1 && "": ;    // treated as a constant integer expression
}
a.c:1:13: warning: variable length array folded to constant array as an extension [-Wgnu-folding-constant]
typedef int A[1 && ""];         // constant integer expression
            ^
a.c:2:12: warning: expression is not an integer constant expression; folding it to a constant is a GNU extension [-Wgnu-folding-constant]
enum { e = 1 && "" };           // constant integer expression
           ^~~~~~~
a.c:3:17: error: static assertion expression is not an integral constant expression
_Static_assert (1 && "", "");   // not a constant integer expression
                ^~~~~~~
a.c:6:19: warning: expression is not an integer constant expression; folding it to a constant is a GNU extension [-Wgnu-folding-constant]
  switch (1) case 1 && "": ;    // constant integer expression
                  ^~~~~~~
3 warnings and 1 error generated.

[intractabilis]

To be clear, the extension I was referring to is treating equality expressions involving string literals as constant integer expressions. The first argument to _Static_assert is just one context where constant integer expressions are required.

Got it. Thank you for very interesting information, and thank you for reopening the bug.

[msebor]

Since I butted in here I feel like I should give it a shot and fix it: my hacky patch is in D134311.

[AaronBallman]

It's worth noting that C2x has updated the standard in this area: WG14 N2713 was adopted for C2x and clarifies: "An implementation may accept other forms of constant expressions, however, they are not an integer constant expression."

[tbaederr]

Should be fixed by a181de4