Build fails with GCC 9 #212
Comments
|
This looks like a bug with GCC. Could you report it there? |
|
Minimal reproduction: https://godbolt.org/z/LIfUzV /*
* C O M P I L E R A N N O T A T I O N S
*
* GCC with -Wextra, and clang by default, complain about overrides in
* initializer lists. Overriding previous member initializers is well
* defined behavior in C. We rely on this behavior to define default,
* overrideable member values when instantiating configuration objects.
*
* quietinit() guards a compound literal expression with pragmas to
* silence these shrill warnings. This alleviates the burden of requiring
* third-party projects to adjust their compiler flags.
*
* NOTE: If you take the address of the compound literal, take the address
* of the transformed expression, otherwise the compound literal lifetime is
* tied to the scope of the GCC statement expression.
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
#if defined __clang__
#define PRAGMA_PUSH _Pragma("clang diagnostic push")
#define PRAGMA_QUIET _Pragma("clang diagnostic ignored \"-Winitializer-overrides\"")
#define PRAGMA_POP _Pragma("clang diagnostic pop")
#define quietinit(...) \
PRAGMA_PUSH PRAGMA_QUIET __VA_ARGS__ PRAGMA_POP
#elif (__GNUC__ == 4 && __GNUC_MINOR__ >= 6) || __GNUC__ > 4
#define PRAGMA_PUSH _Pragma("GCC diagnostic push")
#define PRAGMA_QUIET _Pragma("GCC diagnostic ignored \"-Woverride-init\"")
#define PRAGMA_POP _Pragma("GCC diagnostic pop")
/* GCC parses the _Pragma operator less elegantly than clang. */
#define quietinit(...) \
__extension__ ({ PRAGMA_PUSH PRAGMA_QUIET __VA_ARGS__; PRAGMA_POP })
#else
#define PRAGMA_PUSH
#define PRAGMA_QUIET
#define PRAGMA_POP
#define quietinit(...) __VA_ARGS__
#endif
struct bar {
int a;
};
int main() {
void *x = &quietinit((struct bar){ 0, .a = 0 });
} |
|
@daurnimator: at a quick look, this seems intentional. It's not about overriding the parameters at all. The |
|
If this is an intentional change by GCC, what should the code be instead so that |
|
I can't see such a nice way ATM. Anyway, I think this issue would better be discussed with gcc devs, for a number of reasons. |
|
@wahern please drop in here :) |
|
This patch makes it possible to compile with GCC 9 on Fedora, altough it might cause some issues with clang |
|
Note: GCC 9 was released today, so the problem should soon start affecting more people. |
Hello,
it turns out that latest version of cqueues does not build using GCC 9.
Example:
https://kojipkgs.fedoraproject.org//work/tasks/3269/32433269/build.log
or similarly
This is going to break the package in Fedora 30 which is moving to GCC 9 right now:
https://fedoraproject.org/wiki/Changes/GCC9
The text was updated successfully, but these errors were encountered: