On Sun, Oct 15, 2023 at 7:43 AM Richard Sandiford <richard.sandif...@arm.com> wrote: > > "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
I personally would prefer it if GCC would continue to maintain support for gcc 4.8 for a host compiler. One of the things I like about GCC is how it's generally tried to keep support for older host tools for longer than other projects do, meaning that with GCC, you don't get stuck on the upgrade treadmill of having to compile a whole string of consecutive compilers just to be able to compile the latest one like you have to do with clang. Please just apply Roger's patch; it already exists and is relatively simple.
