Clang and gcc disagree on whether a const struct is a compile-time constant
#44502
Comments
|
assigned to @nickdesaulniers |
|
If I change the Both compilers error if the RHS of the initializer is not declared const. Also, changing the original defintion of |
|
Any use of a "const" variable in a global initializer is an extension in C. It's one of the few extensions that's actually allowed by the C standard, though. Probably makes sense to be compatible with gcc here. |
|
Eli, can you help me find the relevant portion of the standard you're referring to? From the C11 draft, I'm looking at §6.6.7 and §6.7.9. Also, I'm having trouble finding any documentation of this feature on the GCC side. I have this all working, just adding more tests for initializer lists vs designated initialization. |
|
6.6 paragraph 10 says "An implementation may accept other forms of constant expressions". I'm not surprised it isn't documented in gcc; I think gcc implemented the extension by accident, and never formalized it later on. gcc accepts all sorts of weird stuff in global initializers (for example, "int x = x-3-x;"). |
|
Thanks Eli! https://reviews.llvm.org/D76096 |
|
https://reviews.llvm.org/D76096 depends heavily on https://reviews.llvm.org/D151587 which landed as https://reviews.llvm.org/rGb54294e2c9596088aaf557b221bcf471745864bc, which is in release/17.x. |
EugeneZelenko
added
the
clang:frontend
|
@llvm/issue-subscribers-clang-frontend |
|
/branch ClangBuiltLinux/llvm-project/17_const |
…for C
For code like:
struct foo { ... };
struct bar { struct foo foo; };
const struct foo my_foo = { ... };
struct bar my_bar = { .foo = my_foo };
Eli Friedman points out the relevant part of the C standard seems to
have some flexibility in what is considered a constant expression:
6.6 paragraph 10:
An implementation may accept other forms of constant expressions.
GCC 8 added support for these, so clang not supporting them has been a
constant thorn in the side of source code portability within the Linux
kernel.
Fixes: llvm/llvm-project#44502
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76096
(cherry picked from commit 610ec95)
|
/pull-request llvm/llvm-project-release-prs#517 |
…for C
For code like:
struct foo { ... };
struct bar { struct foo foo; };
const struct foo my_foo = { ... };
struct bar my_bar = { .foo = my_foo };
Eli Friedman points out the relevant part of the C standard seems to
have some flexibility in what is considered a constant expression:
6.6 paragraph 10:
An implementation may accept other forms of constant expressions.
GCC 8 added support for these, so clang not supporting them has been a
constant thorn in the side of source code portability within the Linux
kernel.
Fixes: llvm/llvm-project#44502
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76096
(cherry picked from commit 610ec95)
…for C
For code like:
struct foo { ... };
struct bar { struct foo foo; };
const struct foo my_foo = { ... };
struct bar my_bar = { .foo = my_foo };
Eli Friedman points out the relevant part of the C standard seems to
have some flexibility in what is considered a constant expression:
6.6 paragraph 10:
An implementation may accept other forms of constant expressions.
GCC 8 added support for these, so clang not supporting them has been a
constant thorn in the side of source code portability within the Linux
kernel.
Fixes: llvm#44502
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76096
Extended Description
Clang produces:
GCC has no error.
A recent CI run on the Linux kernel failed for Clang on this patch:
https://cgit.freedesktop.org/~jani/drm/commit/?h=device-info-inheritance-v3&id=329fec687c7310f3a68ae1c6fd3638274484f149
The text was updated successfully, but these errors were encountered: