[PATCH] Support g++ 4.8 as a host compiler.

[Iain Sandoe]

> On 8 Oct 2023, at 05:40, Jeff Law <jeffreyalaw@gmail.com> wrote:
> On 10/7/23 15:30, Sam James wrote:
>> Jeff Law <jeffreyalaw@gmail.com> writes:
>>> On 10/4/23 16:19, Roger Sayle wrote:
>>>> The recent patch to remove poly_int_pod triggers a bug in g++
>>>> 4.8.5's
>>>> C++ 11 support which mistakenly believes poly_uint16 has a non-trivial
>>>> constructor.  This in turn prohibits it from being used as a member in
>>>> a union (rtxunion) that constructed statically, resulting in a (fatal)
>>>> error during stage 1.  A workaround is to add an explicit constructor
>>>> to the problematic union, which allows mainline to be bootstrapped with
>>>> the system compiler on older RedHat 7 systems.
>>>> This patch has been tested on x86_64-pc-linux-gnu where it allows a
>>>> bootstrap to complete when using g++ 4.8.5 as the host compiler.
>>>> Ok for mainline?
>>>> 2023-10-04  Roger Sayle  <roger@nextmovesoftware.com>
>>>> gcc/ChangeLog
>>>> 	* rtl.h (rtx_def::u): Add explicit constructor to workaround
>>>> 	issue using g++ 4.8 as a host compiler.
>>> I think the bigger question is whether or not we're going to step
>>> forward on the minimum build requirements.
>>> 
>>> My recollection was we settled on gcc-4.8 for the benefit of RHEL 7
>>> and Centos 7 which are rapidly approaching EOL (June 2024).
>>> 
>>> I would certainly support stepping forward to a more modern compiler
>>> for the build requirements, which might make this patch obsolete.
>> See also richi and jakub's comments at https://inbox.sourceware.org/gcc-patches/mpt5y3ppio0.fsf@arm.com/T/#m985295bedaadb47aa0b9ba63b7cb69a660a108bb.
> Yea.  As Jakub notes, there's the cfarm situation, but I've had good success with DTS on Centos 7 systems (I have to support some of those internally within Ventana).  It quite literally "just works" though users would have to enable it.
> 
> Alternately, update the cfarm hosts?

In practice, if one wants to test Ada and D, a newer toolchain is needed anyway - so at least some of us are already using self-built bootstrap toolchains.

Is there some blocker to installing a project-built toolchain on /opt, for example?  (admittedly it then becomes a point that someone has to take responsibility for providing it).
Iain