This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [EXTERNAL] Re: GCC selftest improvements


> On 2/12/20 8:53 PM, David Malcolm wrote:
> The patch will need an update to the docs; search for
> "Tools/packages necessary for building GCC" in
> gcc/doc/install.texi, which currently has some paragraphs labelled:
>    @item ISO C++98 compiler
> that will need changing.

Added this change in the attached patch. I looked through the rest of the docs folder for "C++98" mentions and found only those pertaining to using it in GCC rather than anything related to bootstrapping. Also did a grep for "C++98" in gcc as a whole and didn’t see any other places regarding bootstrapping. 

I modified how we check for C++11 to use "__cplusplus" since type_traits.h can be present even without full C++11 support.

Testing on x86_64 on Ubuntu 18.04 with gcc 7.4.0 passes. Forcing bootstrap to use gcc 4.7 results in the following configure time error:

**checking that the compiler supports c++11... configure: error: Building GCC requires a compiler that supports c++11, such as GCC 4.8.5 or newer**

I believe RedHat has access to bootstrapping on a variety of platforms/native targets so if I can get someone to validate on those that would be great! That will also give a preview of what targets may have issues before this goes live.

> From: gcc-owner@gcc.gnu.org <gcc-owner@gcc.gnu.org> On Behalf Of Mike
> Stump
> Sent: Friday, February 14, 2020 12:50 PM
> I think we should pick not on the basis something unspecific, rather, I'd list
> the 3 5 or 9 systems we check against, and then pick the minimum of them.
> Above I picked 7.4 because it's on 18.04.  I think this  makes for a better
> policy as it's predicable, stable, and in 100 years, I don't think I see the need
> to change the policy.

I agree with Mike on having a policy in place to guide future efforts in this area. I'm not certain what type of upgrade cadence is needed (check versioning every major Release? Every 2? Note: this doesn't have to be part of the policy) but something consistent means (echoing Mike) there's a default mechanism and a "schedule" of when things are likely to come down the pipeline. 

Also Segher earlier in the thread linked to a great list compiled by Arnd Bergmann that shows Linux recommendations for GCC versioning which looks like a reasonable set of systems to check against. Here's the link again for ease of finding: https://lore.kernel.org/lkml/CAK8P3a3JfUjm88CLqkvAmCoEA1FsmQ33sfHGK4=Y5iuhWxet5Q@mail.gmail.com/

Changelog entry for this patch:

ChangeLog:
2020-02-25 Di Mo  <modimo@microsoft.com>

	* configure.ac: Change bootstrap to test for and require C++11 support
	* configure: regenerate
	* gcc/doc/install.texi: Change bootstrapping requirement to C++11

Modi

Attachment: c++11.patch
Description: c++11.patch


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]