"Roger Sayle" <ro...@nextmovesoftware.com> writes:
> I'd like to ping my patch for restoring bootstrap using g++ 4.8.5
> (the system compiler on RHEL 7 and later systems).
> https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632008.html
>
> Note the preprocessor #ifs can be removed; they are only there to document
> why the union u must have an explicit, empty (but not default) constructor.
>
> I completely agree with the various opinions that we might consider
> upgrading the minimum host compiler for many good reasons (Ada,
> D, newer C++ features etc.). It's inevitable that older compilers and
> systems can't be supported indefinitely.
>
> Having said that I don't think that this unintentional trivial breakage,
> that has a safe one-line work around is sufficient cause (or non-neglible
> risk or support burden), to inconvenice a large number of GCC users
> (the impact/disruption to cfarm has already been mentioned).
>
> Interestingly, "scl enable devtoolset-XX" to use a newer host compiler,
> v10 or v11, results in a significant increase (100+) in unexpected failures I
> see
> during mainline regression testing using "make -k check" (on RedHat 7.9).
> (Older) system compilers, despite their flaws, are selected for their
> (overall) stability and maturity.
>
> If another patch/change hits the compiler next week that reasonably
> means that 4.8.5 can no longer be supported, so be it, but its an
> annoying (and unnecessary?) inconvenience in the meantime.
>
> Perhaps we should file a Bugzilla PR indicating that the documentation
> and release notes need updating, if my fix isn't considered acceptable?
>
> Why this patch is an trigger issue (that requires significant discussion
> and deliberation) is somewhat of a mystery.
It seemed like there was considerable support for bumping the minimum
to beyond 4.8. I think we should wait until a decision has been made
before adding more 4.8 workarounds.
Having a conditional explicit constructor is dangerous because it changes
semantics. E.g. consider:
#include <new>
union u { int x; };
void f(u *ptr) { new(ptr) u; }
void g(u *ptr) { new(ptr) u(); }
g(ptr) zeros ptr->x whereas f(ptr) doesn't. If we add "u() {}" then g()
does not zero ptr->x.
So if we did add the workaround, it would need to be unconditional,
like you say.
Thanks,
Richard
