From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 3F3863858D33 for ; Sun, 15 Oct 2023 11:43:13 +0000 (GMT) ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3F3863858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697370195; cv=none; b=oNB3+SZQglwVoN1sGh3XyIwYH4Htf7dyccWv+fRVH8t7age2Bv0Oz9Q99jvcQkbgAEDsPpI8PXVV6lFawRxhJ2HrPpyh4YwNp/1rny1MTojHfHCC+orMx/FnXt7wOaEjI8316I6+Bmx8Z0GMYM0fVyHf79WqswzCtdjEhe3iDCQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697370195; c=relaxed/simple; bh=/tqwJ2EvedM/PqUs44UoK2eaAKzOwXX+hvAy5TZh3pw=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=KPxWG41TzMWYX1XQ36rvYaupTHW0vbdRo7O5ft+d/5MkzqiEngTO6ihtr/DIhcotcHH7u7YwkxNrYwJKP6sTZxJUsJZGDEPUfNl+o/GcCU/pSWQOtQ/vOrA2KsG6kl5oFfysJzKpmc1gMYD7d7l0oEzlMAuj37YIMDfHn9EWyJA= ARC-Authentication-Results: i=1; server2.sourceware.org DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F3863858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3BED52F4; Sun, 15 Oct 2023 04:43:53 -0700 (PDT) Received: from localhost (unknown [10.32.110.65]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E4B523F7A6; Sun, 15 Oct 2023 04:43:11 -0700 (PDT) From: Richard Sandiford To: "Roger Sayle" Mail-Followup-To: "Roger Sayle" ,"'Jeff Law'" , , "'Richard Biener'" , "'Jakub Jelinek'" , richard.sandiford@arm.com Cc: "'Jeff Law'" , , "'Richard Biener'" , "'Jakub Jelinek'" Subject: Re: [PATCH] Support g++ 4.8 as a host compiler. References: <012a01d9f710$db84ef40$928ecdc0$@nextmovesoftware.com> <7648c11c-11c9-46e9-8e96-5536f87336cc@gmail.com> <00be01d9ff55$76c56010$64502030$@nextmovesoftware.com> Date: Sun, 15 Oct 2023 12:43:10 +0100 In-Reply-To: <00be01d9ff55$76c56010$64502030$@nextmovesoftware.com> (Roger Sayle's message of "Sun, 15 Oct 2023 11:50:49 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-18.1 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: "Roger Sayle" 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 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