Fix #14850 (Compilation fails on oraclelinux:8 (g++ 8.5.0 released in 2021))

[danmar]

No description provided.

[firewave]

This feels like a compiler bug to me.

We should make noexcept optional as a hack for this compiler in question instead of rolling back perfectly valid code.

[firewave]

See also https://trac.cppcheck.net/ticket/14851 to make sure such problems are not just platform-specific.

[danmar]

@firewave thanks for your review.. I also feel these errors are pretty weird. do you have some more specifiec suggestion how we hack it..

how about :

#ifdef GCC_BUG_HACK_NOEXCEPT
#define  NOEXCEPT
#else 
#define  NOEXCEPT  noexcept
#endif

And then I use NOEXCEPT in the constructor and assignment operator?

So when compiling on oraclelinux I will have to provide -DGCC_BUG_HACK_NOEXCEPT

[danmar]

See also https://trac.cppcheck.net/ticket/14851 to make sure such problems are not just platform-specific.

testing more platforms/compilers sounds good to me. we can easily break stuff..

[firewave]

@firewave thanks for your review.. I also feel these errors are pretty weird. do you have some more specifiec suggestion how we hack it..

how about :

#ifdef GCC_BUG_HACK_NOEXCEPT
#define  NOEXCEPT
#else 
#define  NOEXCEPT  noexcept
#endif

And then I use NOEXCEPT in the constructor and assignment operator?

So when compiling on oraclelinux I will have to provide -DGCC_BUG_HACK_NOEXCEPT

Something along those lines. Using gcc -dM -E - < /dev/null you can check the compiler for some platform-specific defines.

[danmar]

Something along those lines. Using gcc -dM -E - < /dev/null you can check the compiler for some platform-specific defines.

I was not sure if it was a g++ 8.5.0 generic bug. Or what versions are affected.

but I now see that we can reproduce with godbolt also...

https://godbolt.org/z/YjGPdxsbK

[firewave]

I was not sure if it was a g++ 8.5.0 generic bug. Or what versions are affected.

but I now see that we can reproduce with godbolt also...

https://godbolt.org/z/YjGPdxsbK

That code appears to be invalid as it doesn't compile at all regardless of version or compiler.

[danmar]

That code appears to be invalid as it doesn't compile at all regardless of version or compiler.

yes .. and when I fix that then 8.5 doesn't complain anymore. :-(
I don't see how to reproduce on godbolt with a short code example unfortunately.
but I have also been able to reproduce the same issue on ubuntu:20.04 which uses g++ 9.4.0 compiler.

[danmar]

@firewave ping could you please look? this blocks a cppcheck premium release as I can't build release binaries.

[firewave]

I have a system which has lots of old GCC versions installed and I wanted to give it a spin with it first but I won't until later today.

[Copilot]

Pull request overview

This PR addresses a GCC ≤9 (not Clang) compilation failure reported on Oracle Linux 8 by relaxing the noexcept specification for Settings move operations under affected compiler versions, and extends CI coverage to include an oraclelinux:8 container build. It also includes a small header formatting cleanup in lib/checks.h.

Changes:

• Add a GCC-version-guarded workaround to omit noexcept on Settings move ctor/assignment for GCC ≤9.
• Add oraclelinux:8 to the Docker-based Unix-ish CI matrix and install required build dependencies.
• Minor namespace closing brace cleanup in lib/checks.h.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
lib/settings.h	Introduces the GCC workaround macro and applies it to Settings move operations.
lib/settings.cpp	Applies the workaround macro to the defaulted move operations’ definitions.
lib/checks.h	Removes an unnecessary trailing semicolon after a namespace block.
.github/workflows/CI-unixish-docker.yml	Adds Oracle Linux 8 to CI and installs dependencies for that container.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[danmar]

I have a system which has lots of old GCC versions installed and I wanted to give it a spin with it first but I won't until later today.

alright I will wait until later today.

[firewave]

I have a system which has lots of old GCC versions installed and I wanted to give it a spin with it first but I won't until later today.

alright I will wait until later today.

Ugh. Won't happen that soon. Something in my main machine broke as it starts but I am only getting a black screen.

[firewave]

The graphics card was simply loose...

I was able to reproduce the issue with GCC 7 to 9 (no earlier version handy) and it is working with GCC 10 and up.