GCC selftest improvements

GCC selftest improvements

[Andrew Dean via gcc]

TLDR: I'd like to propose adding a dependency on a modern unit testing framework to make it easier to write unit tests within GCC. Before I spend much more time on it, what sort of buy-in should I get? Are there any people in particular I should work more closely with as I make this change?
 
Terminology: Within GCC, there are two types of tests in place: unit tests and regression tests. The unit tests have been written with a home-grown selftest framework and run as part of the build process. Any failures to a unit test results in no compiler being produced. The regression tests, on the other hand, run after build, and use the separate DejaGnu framework. In this email, I am only concerning myself with the unit tests, and throughout the remainder of the email, any mention of tests refers to these.
 
Working on GCC, I wanted to add some new unit tests to my feature as I went, but I noticed that there is a good deal of friction involved. Right now, adding new unit tests requires writing the test method, then modifying a second place in the code to call said test method, repeating as necessary until getting all the way to either the selftest.c file or the target hook. There is also no way to do test setup/teardown automatically. Everything is manual.
 
I'd like to propose adding a dependency on a modern open-source unit testing framework as an enhancement to the current self test system. I have used Catch2 (https://github.com/catchorg/Catch2, Boost Software License 1.0) with great success in the past. I experimented with adding it to GCC and converting a handful of tests to use Catch2. Although I only converted a small number of tests, I didn't see any performance impact during selftest. As a bonus, while doing so, I actually found that one test that I had written previously wasn't actually being run, because I had failed to manually call it.
 
Some nice things that Catch2 provides are better error reporting (see below for a comparison), ease of adding new tests (just include the header and write a TEST_CASE(), as opposed to the manual plumbing required right now), extension points for adding custom comparisons (I could see this being very useful to expand on the current rtl test macros), and the ability to run a subset of the tests without recompiling. It is also easy to integrate Catch2 with the existing self-test framework.
 
If this path seems useful to others, I'm happy to pursue it further. A list of work items I see are:
 
1. Convert more tests to verify the claim that build performance is not degraded
2. Update the docs to list Catch2 as the new recommended way to write unit tests
3. If all of the target self-tests are converted, then we can remove the target test hook. Similar for the lang test hook.
 
One thing that would make Catch2 an even more slam-dunk case was if we were able to enable exceptions for the check builds. Then, running the unit tests could report multiple failures at the same time instead of just aborting at the first one. That said, even without enabling exceptions, Catch2 is on par with the current selftest in terms of terminating at the first failure.
 
Another option is to use a test framework that doesn't use exceptions, such as Google Test (https://github.com/google/googletest, BSD 3-Clause "New" or "Revised" License). I personally think Catch2 is more flexible, or I would lead with Google Test. For example, in Catch2, shared setup is done in place with the tests itself, having each subtest be a nested SECTION, where-as in GTest, you have to write a test class that derives from ::test and overrides SetUp(). In addition, the sections in Catch2 can be nested further, allowing several related tests to build on each other. 
 
Here is some sample output for the case where all the tests are passing:
===============================================================================
All tests passed (25 assertions in 5 test cases)
 
And here is the output when a test fails:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
is a Catch v2.9.2 host application.
Run with -? for options
 
-------------------------------------------------------------------------------
test_set_range
-------------------------------------------------------------------------------
../../gcc/bitmap.c:2661
...............................................................................
../../gcc/bitmap.c:2668: FAILED:
  REQUIRE( 6 == bitmap_count_bits (b) )
with expansion:
  6 == 5
 
Catch will terminate because it needed to throw an exception.
The message was: Test failure requires aborting test!
terminate called without an active exception
../../gcc/bitmap.c:2668: FAILED:
  {Unknown expression after the reported line}
due to a fatal error condition:
  SIGABRT - Abort (abnormal termination) signal
===============================================================================
test cases: 2 | 1 passed | 1 failed
assertions: 5 | 3 passed | 2 failed
cc1: internal compiler error: Aborted
<long callstack>
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
 
(Note that at the moment it doesn't know the name of our application or it would have prefixed "is a Catch..." with our app name).
 
Compare that to the output of the current test framework:
../../gcc/bitmap.c:2669: test_set_range: FAIL: ASSERT_EQ ((6), (bitmap_count_bits (b)))
cc1: internal compiler error: in fail, at selftest.c:47
/bin/bash ../../gcc/../move-if-change tmp-macro_list macro_list
echo timestamp > s-macro_list
<long callstack>
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
 
Thanks,
 
Andrew

Re: GCC selftest improvements

[Jonathan Wakely]

On Thu, 24 Oct 2019 at 21:50, Andrew Dean via gcc <gcc@gcc.gnu.org> wrote:
>
> TLDR: I'd like to propose adding a dependency on a modern unit testing framework to make it easier to write unit tests within GCC. Before I spend much more time on it, what sort of buy-in should I get? Are there any people in particular I should work more closely with as I make this change?

Dave Malcolm added the self test framework. He's subscribed to the
list, but I've CC'd him on this mail too.

Re: GCC selftest improvements

[David Malcolm]

On Thu, 2019-10-24 at 20:50 +0000, Andrew Dean via gcc wrote:
> TLDR: I'd like to propose adding a dependency on a modern unit
> testing framework to make it easier to write unit tests within GCC.
> Before I spend much more time on it, what sort of buy-in should I
> get? Are there any people in particular I should work more closely
> with as I make this change?
>  
> Terminology: Within GCC, there are two types of tests in place: unit
> tests and regression tests. The unit tests have been written with a
> home-grown selftest framework and run as part of the build process.
> Any failures to a unit test results in no compiler being produced.
> The regression tests, on the other hand, run after build, and use the
> separate DejaGnu framework. In this email, I am only concerning
> myself with the unit tests, and throughout the remainder of the
> email, any mention of tests refers to these.
>  
> Working on GCC, I wanted to add some new unit tests to my feature as
> I went, but I noticed that there is a good deal of friction involved.
> Right now, adding new unit tests requires writing the test method,
> then modifying a second place in the code to call said test method,
> repeating as necessary until getting all the way to either the
> selftest.c file or the target hook. There is also no way to do test
> setup/teardown automatically. Everything is manual.
>  
> I'd like to propose adding a dependency on a modern open-source unit
> testing framework as an enhancement to the current self test system.
> I have used Catch2 (https://github.com/catchorg/Catch2, Boost
> Software License 1.0) with great success in the past. I experimented
> with adding it to GCC and converting a handful of tests to use
> Catch2. Although I only converted a small number of tests, I didn't
> see any performance impact during selftest. As a bonus, while doing
> so, I actually found that one test that I had written previously
> wasn't actually being run, because I had failed to manually call it.
>  
> Some nice things that Catch2 provides are better error reporting (see
> below for a comparison), ease of adding new tests (just include the
> header and write a TEST_CASE(), as opposed to the manual plumbing
> required right now), extension points for adding custom comparisons
> (I could see this being very useful to expand on the current rtl test
> macros), and the ability to run a subset of the tests without
> recompiling. It is also easy to integrate Catch2 with the existing
> self-test framework.
>  
> If this path seems useful to others, I'm happy to pursue it further.
> A list of work items I see are:
>  
> 1. Convert more tests to verify the claim that build performance is
> not degraded
> 2. Update the docs to list Catch2 as the new recommended way to write
> unit tests
> 3. If all of the target self-tests are converted, then we can remove
> the target test hook. Similar for the lang test hook.
>  
> One thing that would make Catch2 an even more slam-dunk case was if
> we were able to enable exceptions for the check builds. Then, running
> the unit tests could report multiple failures at the same time
> instead of just aborting at the first one. That said, even without
> enabling exceptions, Catch2 is on par with the current selftest in
> terms of terminating at the first failure.
>  
> Another option is to use a test framework that doesn't use
> exceptions, such as Google Test (https://github.com/google/googletest
> , BSD 3-Clause "New" or "Revised" License). I personally think Catch2
> is more flexible, or I would lead with Google Test. For example, in
> Catch2, shared setup is done in place with the tests itself, having
> each subtest be a nested SECTION, where-as in GTest, you have to
> write a test class that derives from ::test and overrides SetUp(). In
> addition, the sections in Catch2 can be nested further, allowing
> several related tests to build on each other. 
>  
> Here is some sample output for the case where all the tests are
> passing:
> =====================================================================
> ==========
> All tests passed (25 assertions in 5 test cases)
>  
> And here is the output when a test fails:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~
> is a Catch v2.9.2 host application.
> Run with -? for options
>  
> -------------------------------------------------------------------
> ------------
> test_set_range
> -------------------------------------------------------------------
> ------------
> ../../gcc/bitmap.c:2661
> .....................................................................
> ..........
> ../../gcc/bitmap.c:2668: FAILED:
>   REQUIRE( 6 == bitmap_count_bits (b) )
> with expansion:
>   6 == 5
>  
> Catch will terminate because it needed to throw an exception.
> The message was: Test failure requires aborting test!
> terminate called without an active exception
> ../../gcc/bitmap.c:2668: FAILED:
>   {Unknown expression after the reported line}
> due to a fatal error condition:
>   SIGABRT - Abort (abnormal termination) signal
> =====================================================================
> ==========
> test cases: 2 | 1 passed | 1 failed
> assertions: 5 | 3 passed | 2 failed
> cc1: internal compiler error: Aborted
> <long callstack>
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.
>  
> (Note that at the moment it doesn't know the name of our application
> or it would have prefixed "is a Catch..." with our app name).
>  
> Compare that to the output of the current test framework:
> ../../gcc/bitmap.c:2669: test_set_range: FAIL: ASSERT_EQ ((6),
> (bitmap_count_bits (b)))
> cc1: internal compiler error: in fail, at selftest.c:47
> /bin/bash ../../gcc/../move-if-change tmp-macro_list macro_list
> echo timestamp > s-macro_list
> <long callstack>
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

Thanks for your email, it looks interesting.  Is your code somewhere we
can see it? 

I'm the author of gcc's selftest framework (and I use it heavily e.g.
for testing the diagnostics subsystem [1]).

It went through substantial changes during review.

I looked over my notes; for reference, here's a summary of the history
of the patches:

v1: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html
  "[PATCH 00/17] RFC: Addding a unit testing framework to gcc"
     Used Google Test framework, was a dummy "frontend"

v2: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01224.html
  "[PATCH/RFC]: unittesting v2: as a plugin (was Re: [PATCH 00/17] RFC:
Addding a unit testing framework to gcc)"
    Still Google Test, as a plugin rather than a frontend

v3: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02947.html
  "[PATCH 00/16] Unit tests framework (v3)"
    Still Google Test, as a plugin built by plugin.exp within DejaGnu
tests, with a custom gtest reporter
    Some discussion about gtest:
      https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03215.html
    
v4: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02379.html
  "[PATCH 00/15] Unittests framework v4: -fself-test"
    Done via "-fself-test" via compiling a dummy file in DejaGnu tests
    I believe it was at this point that I switched to a custom API that
resembles gtest, rather than gtest itself.

v5: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00082.html
  "[PATCH 00/21] Add -fself-test framework for fast, early unit-testing 
(unittests v5)"
    Done via "-fself-test" at each of the 3 stages of bootstrap.

v6: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00210.html
  "[PATCH 00/16] v6 of -fself-test/unit-testing patch"
    Switched to "abort on first failure"
    Eliminated runner class, and from self-registrating tests to manual
test invocation

v7: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00298.html
   "[PATCH] Selftest framework (v7)"
   (one combined patch)

v8: approved; committed v8 to trunk as r237144 (for gcc 7):
   https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00410.html

Notable followups:

2016-07-11:
  * r238209: "Support running the selftests under valgrind"
    * https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00437.html

2017-12-11:
  * r255563: "Expensive selftests: torture testing for fix-it boundary
conditions (PR c/82050)"
    * https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02459.html
    (some tests run as a DejaGnu-built plugin)

2018-04-30:
  * r259782: "selftest: remove "Yoda ordering" in assertions"
    * https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01323.html

2018-10-17:
  * r265240: "Run selftests for C++ as well as C"
    * https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00802.html

I think the consensus during review was that I was over-engineering
things, and that each iteration from v1 to v8 made the code simpler and
involved less C++ "magic", closer to C.  Whether that's still the
consensus I don't know.  Different people within the GCC dev community
have different comfort levels with C++, and my initial version (using
gtest) was probably too "magic" for some.  Maybe people here are more
comfortable with C++ now?

GCC has some rather unique requirements, in that we support a great
many build configurations, some of which are rather primitive - for
example, requiring just C++98 with exceptions disabled, in that we want
to be able to be bootstrappable on relatively "ancient" configurations.
IIRC auto-registration of tests requires that the build configuration
have a sufficiently sane implementation of C++ - having globals with
non-trivial ctors tends to be problematic when dealing with early
implementations of C++.

Personally I don't find the manual registration of tests to be a pain,
but it would be nice to have more readable errors on failures.  There's
probably a case for more verbose test output.  (generally I immediately
just do "make selftest-gdb" on failures; the issue is if it suddenly
starts failing on a build I don't have access to)

I suspect that exceptions would be a deal-breaker; does Catch2 support
-fno-exceptions?

As for setup/teardown, I've been able to do that "manually" using RAII-
style classes in test functions.

Thanks again for your email; hope this is constructive.
Dave

[1] see e.g. the selftests in gcc/input.c and gcc/diagnostic-show-
locus.c

RE: GCC selftest improvements

[Andrew Dean via gcc]

> From: David Malcolm <dmalcolm@redhat.com>
> Sent: Thursday, October 24, 2019 11:18 PM
> On Thu, 2019-10-24 at 20:50 +0000, Andrew Dean via gcc wrote:
> Thanks for your email, it looks interesting.  Is your code somewhere we can see
> it?
It can be -- what is the preferred way to share the code? Though to be honest I can summarize the changes pretty quickly:
1. Add catch.hpp (the single include header from the Catch2 project) and a small wrapper header around catch.hpp that temporarily fixes up some macros that GCC defines to replace c library functions and does nothing if !CHECKING_P
2. Modify test methods like so:
- void test_this_thing ()
+ TEST_CASE("test this thing") 
And
- ASSERT_EQ (a, b);
+ REQUIRE (a == b);
3. Invoke the Catch2 test runner during selftest like:
Catch::Session ().run ();
4. Remove the manual invocations of the test methods, as the TEST_CASE macro takes care of self-registration.

> I think the consensus during review was that I was over-engineering things, and
> that each iteration from v1 to v8 made the code simpler and involved less C++
> "magic", closer to C.  Whether that's still the consensus I don't know.  Different
> people within the GCC dev community have different comfort levels with C++,
> and my initial version (using
> gtest) was probably too "magic" for some.  Maybe people here are more
> comfortable with C++ now?

Here's hoping! Looks like you had a very similar starting point as what I suggested here.

> GCC has some rather unique requirements, in that we support a great many
> build configurations, some of which are rather primitive - for example,
> requiring just C++98 with exceptions disabled, in that we want to be able to be
> bootstrappable on relatively "ancient" configurations.
> IIRC auto-registration of tests requires that the build configuration have a
> sufficiently sane implementation of C++ - having globals with non-trivial ctors
> tends to be problematic when dealing with early implementations of C++.

Is C++98 the limit of what we can use in GCC? If so, that immediately eliminates Catchv1 (C++03), Catch2 (C++11+) and GTest (C++11)
 
> Personally I don't find the manual registration of tests to be a pain, but it would
> be nice to have more readable errors on failures.  There's probably a case for
> more verbose test output.  (generally I immediately just do "make selftest-gdb"
> on failures; the issue is if it suddenly starts failing on a build I don't have access
> to)

I didn't know about selftest-gdb. That will come in handy. My ideal programming style, is to write a new test, watch it fail for the expected reason, then write the production code to make it pass. Having to attach a debugger to validate/investiigate failures slows down the process, as does having to write the additional code to invoke the new test methods, if only by a little bit.
 
> I suspect that exceptions would be a deal-breaker; does Catch2 support -fno-
> exceptions?

Yes, Catch2 supports -fno-exceptions, though not like GTest, which was built to not use exceptions at all. Catch2 stops running tests at the first failure and gives the output as shown in the original email.

> As for setup/teardown, I've been able to do that "manually" using RAII- style
> classes in test functions.

Yes, I have added some RAII classes to assist in testing as well. I just think it will be even better if it were easier to do.

RE: GCC selftest improvements

[Gabriel Dos Reis via gcc]

[Andrew]

| > GCC has some rather unique requirements, in that we support a great many
| > build configurations, some of which are rather primitive - for example,
| > requiring just C++98 with exceptions disabled, in that we want to be able to
| be
| > bootstrappable on relatively "ancient" configurations.
| > IIRC auto-registration of tests requires that the build configuration have a
| > sufficiently sane implementation of C++ - having globals with non-trivial
| ctors
| > tends to be problematic when dealing with early implementations of C++.
| 
| Is C++98 the limit of what we can use in GCC? If so, that immediately
| eliminates Catchv1 (C++03), Catch2 (C++11+) and GTest (C++11)

C++98 was what Diego, Lawrence, Benjamin, Ian, and myself could agreed to back in 2011-2012 when C++11 got just out as a C++ standard, so we couldn't pick C++11 as we didn't have enough G++ out there to count on.

I would expect the situation to have drastically changed - with very handy and popular features such as 'constexpr' (especially with the C++14 relaxation), lambdas and range-for.

Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?

-- Gaby

Re: GCC selftest improvements

[Eric Gallager]

On 10/25/19, Gabriel Dos Reis via gcc <gcc@gcc.gnu.org> wrote:
> [Andrew]
>
> | > GCC has some rather unique requirements, in that we support a great
> many
> | > build configurations, some of which are rather primitive - for example,
> | > requiring just C++98 with exceptions disabled, in that we want to be
> able to
> | be
> | > bootstrappable on relatively "ancient" configurations.
> | > IIRC auto-registration of tests requires that the build configuration
> have a
> | > sufficiently sane implementation of C++ - having globals with
> non-trivial
> | ctors
> | > tends to be problematic when dealing with early implementations of C++.
> |
> | Is C++98 the limit of what we can use in GCC? If so, that immediately
> | eliminates Catchv1 (C++03), Catch2 (C++11+) and GTest (C++11)
>
> C++98 was what Diego, Lawrence, Benjamin, Ian, and myself could agreed to
> back in 2011-2012 when C++11 got just out as a C++ standard, so we couldn't
> pick C++11 as we didn't have enough G++ out there to count on.
>
> I would expect the situation to have drastically changed - with very handy
> and popular features such as 'constexpr' (especially with the C++14
> relaxation), lambdas and range-for.
>
> Jason, Jonathan - is the situation on the terrain really that dire that
> C++11 (or C++14) isn't at all available for platforms that GCC is
> bootstrapped from?
>
> -- Gaby
>

Nicholas Krause was also wanting to move to C++11 recently:
https://gcc.gnu.org/ml/gcc/2019-10/msg00110.html (this month)
https://gcc.gnu.org/ml/gcc/2019-09/msg00228.html (last month)
As I said in that thread, I'd want to try just toggling -Wnarrowing
from off to on first before going full C++11. So, GCC 10 would be
C++98 + -Wnarrowing, and then GCC 11 could be full C++11. Plus then
the GCC version numbers would also line up with the version of C++
being used.

Eric

Re: GCC selftest improvements

[Pedro Alves]

On 10/26/19 11:46 PM, Eric Gallager wrote:

> Nicholas Krause was also wanting to move to C++11 recently:
> https://gcc.gnu.org/ml/gcc/2019-10/msg00110.html (this month)
> https://gcc.gnu.org/ml/gcc/2019-09/msg00228.html (last month)
> As I said in that thread, I'd want to try just toggling -Wnarrowing
> from off to on first before going full C++11. 

Why?  GDB went the other way when it moved to C++11.  It switched
to C++11, and for several months, used -Wno-narrowing to quiet
the thousands of warnings.

https://gcc.gnu.org/wiki/FAQ#Wnarrowing

> So, GCC 10 would be
> C++98 + -Wnarrowing, and then GCC 11 could be full C++11. Plus then
> the GCC version numbers would also line up with the version of C++
> being used.

Thanks,
Pedro Alves

Re: GCC selftest improvements

[Eric Gallager]

On 10/31/19, Pedro Alves <pedro@palves.net> wrote:
> On 10/26/19 11:46 PM, Eric Gallager wrote:
>
>> Nicholas Krause was also wanting to move to C++11 recently:
>> https://gcc.gnu.org/ml/gcc/2019-10/msg00110.html (this month)
>> https://gcc.gnu.org/ml/gcc/2019-09/msg00228.html (last month)
>> As I said in that thread, I'd want to try just toggling -Wnarrowing
>> from off to on first before going full C++11.
>
> Why?  GDB went the other way when it moved to C++11.  It switched
> to C++11, and for several months, used -Wno-narrowing to quiet
> the thousands of warnings.
>
> https://gcc.gnu.org/wiki/FAQ#Wnarrowing

Sorry, lost track of this conversation in the end-of-month mail
archive rollover... Uh, to be honest, I guess I don't really have a
rational reason for wanting to switch to -Wnarrowing first; it's
really more of an emotional/aesthetic desire I have on my part... Feel
free to do the switch in the other order if that turns out to be
easier. Anyways, from the rest of the discussion, it looks like this
will be waiting for GCC 11 anyways, so I'm already getting my "hold
off 1 release" wish, so I guess I don't really care as much about the
-Wnarrowing part as much any longer...

Eric

>
>> So, GCC 10 would be
>> C++98 + -Wnarrowing, and then GCC 11 could be full C++11. Plus then
>> the GCC version numbers would also line up with the version of C++
>> being used.
>
> Thanks,
> Pedro Alves
>

RE: [EXTERNAL] Re: GCC selftest improvements

[Modi Mo via gcc]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

Hey all,

I'm picking this work up from Andrew. Last time it was decided that the timing wasn't right to upgrade the minimum version to C++11. Is the timing better now to get this change through?

I've attached the patch Andrew prepared. Can I get feedback on the change and some help testing on the broader range of architectures/platforms? 

Thanks,
Modi

[-- Attachment #2: c++11.patch --]
[-- Type: application/octet-stream, Size: 1080 bytes --]

diff --git a/configure.ac b/configure.ac
index df2af18f9bd..4afd4f813f6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1439,11 +1439,19 @@ case "$have_compiler:$host:$target:$enable_bootstrap" in
     ;;
 esac
 
-# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a
-# C++98 compiler can still start the bootstrap.
-if test "$enable_bootstrap:$GXX" = "yes:yes"; then
-  CXX="$CXX -std=gnu++98"
-fi
+# When bootstrapping with GCC, build stage 1 in C++11 mode to ensure that a 
+# C++11 compiler can still start the bootstrap. 
+if test "$enable_bootstrap:$GXX" = "yes:yes"; then 
+  CXX="$CXX -std=gnu++11" 
+ 
+  AC_LANG_PUSH(C++) 
+  AC_MSG_CHECKING([that the compiler supports c++11]) 
+  AC_TRY_COMPILE([#include <type_traits>],[], [AC_MSG_RESULT([yes]); supports_cpp11=yes], [AC_MSG_RESULT([no]); supports_cpp11=no]) 
+  if test x$supports_cpp11 != xyes; then 
+    AC_MSG_ERROR([Building GCC requires a compiler that supports c++11, such as GCC 4.8.1 or newer]) 
+  fi 
+  AC_LANG_POP(C++) 
+fi 
 
 # Used for setting $lt_cv_objdir
 _LT_CHECK_OBJDIR

Re: [EXTERNAL] Re: GCC selftest improvements

[David Malcolm]

On Thu, 2020-02-13 at 00:49 +0000, Modi Mo wrote:
> Hey all,
> 
> I'm picking this work up from Andrew. Last time it was decided that
> the timing wasn't right to upgrade the minimum version to C++11. Is
> the timing better now to get this change through?
> 
> I've attached the patch Andrew prepared. Can I get feedback on the
> change and some help testing on the broader range of
> architectures/platforms? 
> 
> Thanks,
> Modi

Hi Modi

Thanks for the patch.

Some nitpicks:

Timing-wise, the GCC developer community is focusing on gcc 10
bugfixing right now (aka "stage 4" of the release cycle).  So this
patch won't be suitable to commit to master until stage 1 of the
release cycle for gcc 11 (in April, hopefully).

But yes, it's probably a good idea to get feedback on the patch given
the breadth of platforms we support.

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.

I think Richi mentioned that the minimum gcc version should be 4.8.2 as
he recalled issues with .1, so maybe the error message and docs should
reflect that?
  https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html


This may be opening a can of worms that should wait until we're done
with the GCC 10 release, but there's probably an eventual wider
discussion about what parts of C++11 we should use; pragmatically we're
also limited by gengtype, the tool that scrapes the source code looking
for garbage-collector markup, as that imposes a subset of C++ on us.

I'd love to be able to rely on move semantics and thus use e.g.
std::unique_ptr to capture more of our memory-management in the type
system (we currently have a limited C++98-compatible implementation in
the tree in the form of gnu::unique_ptr).

How much of the stdlib do we see ourselves using?  I think we've
avoided std::string and the <<-style stream APIs; is there a case for
using some of the other data structures?

For reference, see
  https://gcc.gnu.org/codingconventions.html#Cxx_Conventions
(looks like that page would need an update also for the version bump;
it's in the website git repo IIRC)

Hope this is constructive.
Dave

Re: [EXTERNAL] Re: GCC selftest improvements

[Nicholas Krause]

On 2/12/20 8:53 PM, David Malcolm wrote:
> On Thu, 2020-02-13 at 00:49 +0000, Modi Mo wrote:
>> Hey all,
>>
>> I'm picking this work up from Andrew. Last time it was decided that
>> the timing wasn't right to upgrade the minimum version to C++11. Is
>> the timing better now to get this change through?
>>
>> I've attached the patch Andrew prepared. Can I get feedback on the
>> change and some help testing on the broader range of
>> architectures/platforms?
>>
>> Thanks,
>> Modi
> Hi Modi
>
> Thanks for the patch.
>
> Some nitpicks:
>
> Timing-wise, the GCC developer community is focusing on gcc 10
> bugfixing right now (aka "stage 4" of the release cycle).  So this
> patch won't be suitable to commit to master until stage 1 of the
> release cycle for gcc 11 (in April, hopefully).
>
> But yes, it's probably a good idea to get feedback on the patch given
> the breadth of platforms we support.
>
> 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.
>
> I think Richi mentioned that the minimum gcc version should be 4.8.2 as
> he recalled issues with .1, so maybe the error message and docs should
> reflect that?
>    https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html
>
>
> This may be opening a can of worms that should wait until we're done
> with the GCC 10 release, but there's probably an eventual wider
> discussion about what parts of C++11 we should use; pragmatically we're
> also limited by gengtype, the tool that scrapes the source code looking
> for garbage-collector markup, as that imposes a subset of C++ on us.
>
> I'd love to be able to rely on move semantics and thus use e.g.
> std::unique_ptr to capture more of our memory-management in the type
> system (we currently have a limited C++98-compatible implementation in
> the tree in the form of gnu::unique_ptr).
>
> How much of the stdlib do we see ourselves using?  I think we've
> avoided std::string and the <<-style stream APIs; is there a case for
> using some of the other data structures?
>
> For reference, see
>    https://gcc.gnu.org/codingconventions.html#Cxx_Conventions
> (looks like that page would need an update also for the version bump;
> it's in the website git repo IIRC)
>
> Hope this is constructive.
> Dave
Dave,

I recall originally bringing up the move. From memory I recall that 
these were the
features we wanted or the people in the discussion wanted from C++11:
1. Better Rounding and Stricter Integer and other number type rules
2. Template Aliasing
3. Auto and for each style loops
4. Move and R Value Semantics

There was a little discussion about lambas and anonymous functions but I 
don't
recall that being clear in terms of one of the above areas for sure.

Maybe that helps,
Nick

RE: [EXTERNAL] Re: GCC selftest improvements

[Modi Mo via gcc]

> On 2/12/20 8:53 PM, David Malcolm wrote:
> > Thanks for the patch.
> >
> > Some nitpicks:
> >
> > Timing-wise, the GCC developer community is focusing on gcc 10
> > bugfixing right now (aka "stage 4" of the release cycle).  So this
> > patch won't be suitable to commit to master until stage 1 of the
> > release cycle for gcc 11 (in April, hopefully).
> >

Ah I should've looked a bit harder for timelines before asking https://gcc.gnu.org/develop.html. Appreciate the response here!

> > But yes, it's probably a good idea to get feedback on the patch given
> > the breadth of platforms we support.
> >
> > 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.
> >
> > I think Richi mentioned that the minimum gcc version should be 4.8.2
> > as he recalled issues with .1, so maybe the error message and docs
> > should reflect that?
> >
> > https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html
> >

Segher here suggests 4.8.5 instead of 4.8.2: 
https://gcc.gnu.org/ml/gcc/2019-11/msg00192.html

Looking at release dates 4.8.5 was in June 2015 while 4.8.2 in October 2013 which is a pretty big gap. I'd for moving the needle as far as we reasonably can since this is a leap anyways. @Segher do you have a reason in mind for the higher versioning?
> > This may be opening a can of worms that should wait until we're done
> > with the GCC 10 release, but there's probably an eventual wider
> > discussion about what parts of C++11 we should use; pragmatically
> > we're also limited by gengtype, the tool that scrapes the source code
> > looking for garbage-collector markup, as that imposes a subset of C++ on us.
> >
> > I'd love to be able to rely on move semantics and thus use e.g.
> > std::unique_ptr to capture more of our memory-management in the type
> > system (we currently have a limited C++98-compatible implementation in
> > the tree in the form of gnu::unique_ptr).
> >
> > How much of the stdlib do we see ourselves using?  I think we've
> > avoided std::string and the <<-style stream APIs; is there a case for
> > using some of the other data structures?
> >
> > For reference, see
> >
> > https://gcc.gnu.org/codingconventions.html#Cxx_Conventions
> >
> > Hope this is constructive.
> > Dave
> Dave,
> 
> I recall originally bringing up the move. From memory I recall that these were
> the features we wanted or the people in the discussion wanted from C++11:
> 1. Better Rounding and Stricter Integer and other number type rules 2. Template
> Aliasing 3. Auto and for each style loops 4. Move and R Value Semantics
> 

Agreed on these features. I really like having access to 'for (const auto & foo : bar)'
> There was a little discussion about lambas and anonymous functions but I don't
> recall that being clear in terms of one of the above areas for sure.
> 
> Maybe that helps,
> Nick

C++11 bootstrap (was: GCC selftest improvements)

[Jason Merrill]

On Thu, Feb 13, 2020 at 11:18 PM Modi Mo <modimo@microsoft.com> wrote:
>
> > On 2/12/20 8:53 PM, David Malcolm wrote:
> > > Thanks for the patch.
> > >
> > > Some nitpicks:
> > >
> > > Timing-wise, the GCC developer community is focusing on gcc 10
> > > bugfixing right now (aka "stage 4" of the release cycle).  So this
> > > patch won't be suitable to commit to master until stage 1 of the
> > > release cycle for gcc 11 (in April, hopefully).
> > >
>
> Ah I should've looked a bit harder for timelines before asking https://gcc.gnu.org/develop.html. Appreciate the response here!
>
> > > But yes, it's probably a good idea to get feedback on the patch given
> > > the breadth of platforms we support.
> > >
> > > 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.
> > >
> > > I think Richi mentioned that the minimum gcc version should be 4.8.2
> > > as he recalled issues with .1, so maybe the error message and docs
> > > should reflect that?
> > >
> > > https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html
> > >
>
> Segher here suggests 4.8.5 instead of 4.8.2:
> https://gcc.gnu.org/ml/gcc/2019-11/msg00192.html
>
> Looking at release dates 4.8.5 was in June 2015 while 4.8.2 in October 2013 which is a pretty big gap. I'd for moving the needle as far as we reasonably can since this is a leap anyways. @Segher do you have a reason in mind for the higher versioning?
> > > This may be opening a can of worms that should wait until we're done
> > > with the GCC 10 release, but there's probably an eventual wider
> > > discussion about what parts of C++11 we should use; pragmatically
> > > we're also limited by gengtype, the tool that scrapes the source code
> > > looking for garbage-collector markup, as that imposes a subset of C++ on us.
> > >
> > > I'd love to be able to rely on move semantics and thus use e.g.
> > > std::unique_ptr to capture more of our memory-management in the type
> > > system (we currently have a limited C++98-compatible implementation in
> > > the tree in the form of gnu::unique_ptr).
> > >
> > > How much of the stdlib do we see ourselves using?  I think we've
> > > avoided std::string and the <<-style stream APIs; is there a case for
> > > using some of the other data structures?
> > >
> > > For reference, see
> > >
> > > https://gcc.gnu.org/codingconventions.html#Cxx_Conventions
> > >
> > > Hope this is constructive.
> > > Dave
> > Dave,
> >
> > I recall originally bringing up the move. From memory I recall that these were
> > the features we wanted or the people in the discussion wanted from C++11:
> > 1. Better Rounding and Stricter Integer and other number type rules 2. Template
> > Aliasing 3. Auto and for each style loops 4. Move and R Value Semantics
> >
>
> Agreed on these features. I really like having access to 'for (const auto & foo : bar)'
> > There was a little discussion about lambas and anonymous functions but I don't
> > recall that being clear in terms of one of the above areas for sure.

For information, bootstrap with 4.8.5 -std=gnu++11 works now with no
other changes.  It seems the only other changes needed will be to
documentation.

Jason

Re: [EXTERNAL] Re: GCC selftest improvements

[Segher Boessenkool]

Hi!

On Thu, Feb 13, 2020 at 10:18:27PM +0000, Modi Mo via gcc wrote:
> Segher here suggests 4.8.5 instead of 4.8.2: 
> https://gcc.gnu.org/ml/gcc/2019-11/msg00192.html

I said as long as 4.8.5 works, it is fine with me.  If 4.8.2 can be made
to work easily that is useful for the few people who would want to run
GCC 11 on Ubuntu 14 ("Trusty") (note this is EOL already).

> Looking at release dates 4.8.5 was in June 2015 while 4.8.2 in October 2013 which is a pretty big gap. I'd for moving the needle as far as we reasonably can since this is a leap anyways. @Segher do you have a reason in mind for the higher versioning?

It's just that that is the latest 4.8 release, and it is what I see on
all still supported systems that use 4.8.

Arnd Bergmann made a neat overview showing this (and many other things):
https://lore.kernel.org/lkml/CAK8P3a3JfUjm88CLqkvAmCoEA1FsmQ33sfHGK4=Y5iuhWxet5Q@mail.gmail.com/


Segher

Re: [EXTERNAL] Re: GCC selftest improvements

[Jeff Law]

On Thu, 2020-02-13 at 22:18 +0000, Modi Mo wrote:
> > On 2/12/20 8:53 PM, David Malcolm wrote:
> > > Thanks for the patch.
> > > 
> > > Some nitpicks:
> > > 
> > > Timing-wise, the GCC developer community is focusing on gcc 10
> > > bugfixing right now (aka "stage 4" of the release cycle).  So this
> > > patch won't be suitable to commit to master until stage 1 of the
> > > release cycle for gcc 11 (in April, hopefully).
> > > 
> 
> Ah I should've looked a bit harder for timelines before asking https://gcc.gnu.org/develop.html. Appreciate the response here!
> 
> > > But yes, it's probably a good idea to get feedback on the patch given
> > > the breadth of platforms we support.
> > > 
> > > 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.
> > > 
> > > I think Richi mentioned that the minimum gcc version should be 4.8.2
> > > as he recalled issues with .1, so maybe the error message and docs
> > > should reflect that?
> > > 
> > > https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html
> > > 
> 
> Segher here suggests 4.8.5 instead of 4.8.2: 
> https://gcc.gnu.org/ml/gcc/2019-11/msg00192.html
> 
> Looking at release dates 4.8.5 was in June 2015 while 4.8.2 in October 2013 which is a pretty big gap. I'd for moving the needle as far as we reasonably can since this is a leap anyways. @Segher do you have a reason in mind for the higher versioning?
I doubt there's a lot of functional difference between 4.8.5 and 4.8.2.
It really should just be bugfixes.    While I'd prefer 4.8.5 over
4.8.2, I could live with either.

Jeff

RE: [EXTERNAL] Re: GCC selftest improvements

[Modi Mo via gcc]

[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]

> 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 #2: c++11.patch --]
[-- Type: application/octet-stream, Size: 5934 bytes --]

diff --git a/configure b/configure
index abd93a990a94..87f514387cf0 100755
--- a/configure
+++ b/configure
@@ -754,6 +754,7 @@ infodir
 docdir
 oldincludedir
 includedir
+runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -919,6 +920,7 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
+runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE}'
@@ -1171,6 +1173,15 @@ do
   | -silent | --silent | --silen | --sile | --sil)
     silent=yes ;;
 
+  -runstatedir | --runstatedir | --runstatedi | --runstated \
+  | --runstate | --runstat | --runsta | --runst | --runs \
+  | --run | --ru | --r)
+    ac_prev=runstatedir ;;
+  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
+  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
+  | --run=* | --ru=* | --r=*)
+    runstatedir=$ac_optarg ;;
+
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
     ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1308,7 +1319,7 @@ fi
 for ac_var in	exec_prefix prefix bindir sbindir libexecdir datarootdir \
 		datadir sysconfdir sharedstatedir localstatedir includedir \
 		oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-		libdir localedir mandir
+		libdir localedir mandir runstatedir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1468,6 +1479,7 @@ Fine tuning of the installation directories:
   --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
+  --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIR            object code libraries [EPREFIX/lib]
   --includedir=DIR        C header files [PREFIX/include]
   --oldincludedir=DIR     C header files for non-gcc [/usr/include]
@@ -5434,10 +5446,50 @@ $as_echo "$as_me: WARNING: trying to bootstrap a cross compiler" >&2;}
     ;;
 esac
 
-# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a
-# C++98 compiler can still start the bootstrap.
+# When bootstrapping with GCC, build stage 1 in C++11 mode to ensure that a
+# C++11 compiler can still start the bootstrap.
 if test "$enable_bootstrap:$GXX" = "yes:yes"; then
-  CXX="$CXX -std=gnu++98"
+  CXX="$CXX -std=gnu++11"
+
+  ac_ext=cpp
+ac_cpp='$CXXCPP $CPPFLAGS'
+ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CXX -o conftest$ac_exeext $CXXFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
+
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking that the compiler supports c++11" >&5
+$as_echo_n "checking that the compiler supports c++11... " >&6; }
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  #if __cplusplus < 201103L
+  ruh oh
+  #endif
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_compile "$LINENO"; then :
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
+$as_echo "yes" >&6; }; supports_cpp11=yes
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }; supports_cpp11=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+  if test x$supports_cpp11 != xyes; then
+    as_fn_error $? "Building GCC requires a compiler that supports c++11, such as GCC 4.8.5 or newer" "$LINENO" 5
+  fi
+  ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
 fi
 
 # Used for setting $lt_cv_objdir
diff --git a/configure.ac b/configure.ac
index 9db4fd14aa23..287cace24bde 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1380,11 +1380,22 @@ case "$have_compiler:$host:$target:$enable_bootstrap" in
     ;;
 esac
 
-# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a
-# C++98 compiler can still start the bootstrap.
-if test "$enable_bootstrap:$GXX" = "yes:yes"; then
-  CXX="$CXX -std=gnu++98"
-fi
+# When bootstrapping with GCC, build stage 1 in C++11 mode to ensure that a 
+# C++11 compiler can still start the bootstrap. 
+if test "$enable_bootstrap:$GXX" = "yes:yes"; then 
+  CXX="$CXX -std=gnu++11" 
+ 
+  AC_LANG_PUSH(C++) 
+  AC_MSG_CHECKING([that the compiler supports c++11]) 
+  AC_TRY_COMPILE([],[
+  #if __cplusplus < 201103L
+  ruh oh
+  #endif], [AC_MSG_RESULT([yes]); supports_cpp11=yes], [AC_MSG_RESULT([no]); supports_cpp11=no]) 
+  if test x$supports_cpp11 != xyes; then 
+    AC_MSG_ERROR([Building GCC requires a compiler that supports c++11, such as GCC 4.8.5 or newer]) 
+  fi 
+  AC_LANG_POP(C++) 
+fi 
 
 # Used for setting $lt_cv_objdir
 _LT_CHECK_OBJDIR
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 911875f9578f..e7c96d58b0c2 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -239,11 +239,12 @@ described below.
 
 @heading Tools/packages necessary for building GCC
 @table @asis
-@item ISO C++98 compiler
-Necessary to bootstrap GCC, although versions of GCC prior
-to 4.8 also allow bootstrapping with a ISO C89 compiler and versions
-of GCC prior to 3.4 also allow bootstrapping with a traditional
-(K&R) C compiler.
+@item ISO C++11 compiler
+Necessary to bootstrap GCC. When using GCC to bootstrap itself we recommend 
+using GCC 4.8.5 or higher as the bootstrapping compiler. Versions of GCC 
+prior to 4.8 also allow bootstrapping with a ISO C89 compiler and versions 
+of GCC prior to 3.4 also allow bootstrapping with a traditional (K&R) C 
+compiler.
 
 To build all languages in a cross-compiler or other configuration where
 3-stage bootstrap is not performed, you need to start with an existing

Re: [EXTERNAL] Re: GCC selftest improvements

[David Malcolm]

On Tue, 2020-02-25 at 19:58 +0000, Modi Mo wrote:
> > 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.

Thanks Modi.

Before looking at the updated patch in detail, we ought to also address
the legal prerequisites for contributing.

Does your employer have legal paperwork in place with the FSF for such
contributions?  See:
  https://gcc.gnu.org/contribute.html#legal

I'm not sure what the threshold is for a contribution to be regarded as
"significant", but it seems that we ought to be fastidious here, given
historical attitudes between Microsoft and the FLOSS community.

(I'm not speaking on behalf of anyone other than myself here, as a GCC
maintainer, and I don't mean for this to come across as personal)

Thanks
Dave

Re: [EXTERNAL] Re: GCC selftest improvements

[Gabriel Dos Reis via gcc]

Thanks, Dave.  We will work on the legal papers with FSF.

-- Gaby
________________________________
From: David Malcolm <dmalcolm@redhat.com>
Sent: Tuesday, February 25, 2020 2:10:59 PM
To: Modi Mo <modimo@microsoft.com>; law@redhat.com <law@redhat.com>; Nicholas Krause <xerofoify@gmail.com>; Eric Gallager <egall@gwmail.gwu.edu>; Pedro Alves <pedro@palves.net>
Cc: Gabriel Dos Reis <gdr@microsoft.com>; Andrew Dean <Andrew.Dean@microsoft.com>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ro@CeBiTec.Uni-Bielefeld.DE <ro@cebitec.uni-bielefeld.de>; mikestump@comcast.net <mikestump@comcast.net>; jason@redhat.com <jason@redhat.com>; Jonathan Wakely <cxx@kayari.org>; Richard Biener <richard.guenther@gmail.com>
Subject: Re: [EXTERNAL] Re: GCC selftest improvements

On Tue, 2020-02-25 at 19:58 +0000, Modi Mo wrote:
> > 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.

Thanks Modi.

Before looking at the updated patch in detail, we ought to also address
the legal prerequisites for contributing.

Does your employer have legal paperwork in place with the FSF for such
contributions?  See:
  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fcontribute.html%23legal&amp;data=02%7C01%7Cgdr%40microsoft.com%7C78624c908d354c815f9d08d7ba3fa1f6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637182654788877774&amp;sdata=8GiCH%2FijVByqeO6e9qdRw3C09o0Suh62Gf8kq2HYe%2B4%3D&amp;reserved=0

I'm not sure what the threshold is for a contribution to be regarded as
"significant", but it seems that we ought to be fastidious here, given
historical attitudes between Microsoft and the FLOSS community.

(I'm not speaking on behalf of anyone other than myself here, as a GCC
maintainer, and I don't mean for this to come across as personal)

Thanks
Dave

RE: [EXTERNAL] Re: GCC selftest improvements

[Modi Mo via gcc]

> From: David Malcolm <dmalcolm@redhat.com>
> 
> Thanks Modi.
> 
> Before looking at the updated patch in detail, we ought to also address the
> legal prerequisites for contributing.
> 
> Does your employer have legal paperwork in place with the FSF for such
> contributions?  See:
> 
> https://gcc.gnu.org/contribute.html#legal
> 
> I'm not sure what the threshold is for a contribution to be regarded as
> "significant", but it seems that we ought to be fastidious here, given historical
> attitudes between Microsoft and the FLOSS community.
> 
> (I'm not speaking on behalf of anyone other than myself here, as a GCC
> maintainer, and I don't mean for this to come across as personal)
> 
> Thanks
> Dave

Guidance from my side is to get an individual's license to proceed. Can you send me over the forms to get that done?

Modi

Re: GCC selftest improvements

[Jeff Law]

On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
> [Andrew]
> 
> | > GCC has some rather unique requirements, in that we support a great many
> | > build configurations, some of which are rather primitive - for example,
> | > requiring just C++98 with exceptions disabled, in that we want to be able to
> | be
> | > bootstrappable on relatively "ancient" configurations.
> | > IIRC auto-registration of tests requires that the build configuration have a
> | > sufficiently sane implementation of C++ - having globals with non-trivial
> | ctors
> | > tends to be problematic when dealing with early implementations of C++.
> | 
> | Is C++98 the limit of what we can use in GCC? If so, that immediately
> | eliminates Catchv1 (C++03), Catch2 (C++11+) and GTest (C++11)
> 
> C++98 was what Diego, Lawrence, Benjamin, Ian, and myself could agreed to back in 2011-2012 when C++11 got just out as a C++ standard, so we couldn't pick C++11 as we didn't have enough G++ out there to count on.
> 
> I would expect the situation to have drastically changed - with very handy and popular features such as 'constexpr' (especially with the C++14 relaxation), lambdas and range-for.
> 
> Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?
The argument that I'd make is that's relatively uncommon (I know, I know
AIX) that bootstrapping in those environments may well require first
building something like gcc-9.

I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
we have any good mechanism for making this kind of technical decision
when there isn't consensus.

jeff

Re: GCC selftest improvements

[Richard Biener]

On October 28, 2019 8:40:03 PM GMT+01:00, Jeff Law <law@redhat.com> wrote:
>On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
>> [Andrew]
>> 
>> | > GCC has some rather unique requirements, in that we support a
>great many
>> | > build configurations, some of which are rather primitive - for
>example,
>> | > requiring just C++98 with exceptions disabled, in that we want to
>be able to
>> | be
>> | > bootstrappable on relatively "ancient" configurations.
>> | > IIRC auto-registration of tests requires that the build
>configuration have a
>> | > sufficiently sane implementation of C++ - having globals with
>non-trivial
>> | ctors
>> | > tends to be problematic when dealing with early implementations
>of C++.
>> | 
>> | Is C++98 the limit of what we can use in GCC? If so, that
>immediately
>> | eliminates Catchv1 (C++03), Catch2 (C++11+) and GTest (C++11)
>> 
>> C++98 was what Diego, Lawrence, Benjamin, Ian, and myself could
>agreed to back in 2011-2012 when C++11 got just out as a C++ standard,
>so we couldn't pick C++11 as we didn't have enough G++ out there to
>count on.
>> 
>> I would expect the situation to have drastically changed - with very
>handy and popular features such as 'constexpr' (especially with the
>C++14 relaxation), lambdas and range-for.
>> 
>> Jason, Jonathan - is the situation on the terrain really that dire
>that C++11 (or C++14) isn't at all available for platforms that GCC is
>bootstrapped from?
>The argument that I'd make is that's relatively uncommon (I know, I
>know
>AIX) that bootstrapping in those environments may well require first
>building something like gcc-9.
>
>I'd really like to see us move to C++11 or beyond.  Sadly, I don't
>think
>we have any good mechanism for making this kind of technical decision
>when there isn't consensus.

Well, we just do it?

Richard. 

>jeff

Re: GCC selftest improvements

[Jeff Law]

On 10/28/19 1:42 PM, Richard Biener wrote:
>>
>> I'd really like to see us move to C++11 or beyond.  Sadly, I don't
>> think
>> we have any good mechanism for making this kind of technical decision
>> when there isn't consensus.
> 
> Well, we just do it?
For some reason I thought you were against such a change.  Was I wrong?

jeff

RE: GCC selftest improvements

[Gabriel Dos Reis via gcc]

| -----Original Message-----
| From: Jeff Law <law@redhat.com>
| Sent: Monday, October 28, 2019 12:44 PM
| To: Richard Biener <richard.guenther@gmail.com>; gcc@gcc.gnu.org;
| Gabriel Dos Reis <gdr@microsoft.com>; Andrew Dean
| <Andrew.Dean@microsoft.com>; David Malcolm <dmalcolm@redhat.com>;
| ro@CeBiTec.Uni-Bielefeld.DE; mikestump@comcast.net;
| jason@redhat.com; Jonathan Wakely <cxx@kayari.org>
| Subject: Re: GCC selftest improvements
| 
| On 10/28/19 1:42 PM, Richard Biener wrote:
| >>
| >> I'd really like to see us move to C++11 or beyond.  Sadly, I don't
| >> think
| >> we have any good mechanism for making this kind of technical decision
| >> when there isn't consensus.
| >
| > Well, we just do it?
| For some reason I thought you were against such a change.  Was I wrong?

I suspect Andrew would be happy to contribute patch and any follow up.

-- Gaby

Re: GCC selftest improvements

[Segher Boessenkool]

On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
> > Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?
> The argument that I'd make is that's relatively uncommon (I know, I know
> AIX) that bootstrapping in those environments may well require first
> building something like gcc-9.
> 
> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
> we have any good mechanism for making this kind of technical decision
> when there isn't consensus.

Which GCC version will be required to work as bootstrap compiler?  Will
4.8.5 be enough?


Segher

Re: GCC selftest improvements

[Jeff Law]

On 10/28/19 2:27 PM, Segher Boessenkool wrote:
> On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
>> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
>>> Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?
>> The argument that I'd make is that's relatively uncommon (I know, I know
>> AIX) that bootstrapping in those environments may well require first
>> building something like gcc-9.
>>
>> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
>> we have any good mechanism for making this kind of technical decision
>> when there isn't consensus.
> 
> Which GCC version will be required to work as bootstrap compiler?  Will
> 4.8.5 be enough?
I'd say gcc-9.  What would we gain by making it 4.8 or anything else
that old?

jeff

Re: GCC selftest improvements

[Jakub Jelinek]

On Mon, Oct 28, 2019 at 03:41:13PM -0600, Jeff Law wrote:
> On 10/28/19 2:27 PM, Segher Boessenkool wrote:
> > On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
> >> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
> >>> Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?
> >> The argument that I'd make is that's relatively uncommon (I know, I know
> >> AIX) that bootstrapping in those environments may well require first
> >> building something like gcc-9.
> >>
> >> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
> >> we have any good mechanism for making this kind of technical decision
> >> when there isn't consensus.
> > 
> > Which GCC version will be required to work as bootstrap compiler?  Will
> > 4.8.5 be enough?
> I'd say gcc-9.  What would we gain by making it 4.8 or anything else
> that old?

That is not a good idea, it will make it much harder to build gcc because
not everybody has gcc-9 built as a system compiler.
The previous minimum requirement of 4.1 is perhaps too old now that 4.8 is
something we could require and gain through that C++11 support, but we
shouldn't follow Rust with "you can only build it with 6 weeks old previous
release and nothing else".
As discussed earlier, we gain most through C++11 support, there is no need
to jump to C++17 or C++20 as requirement.

	Jakub

Re: GCC selftest improvements

[Andrew Pinski]

On Mon, Oct 28, 2019 at 2:47 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Mon, Oct 28, 2019 at 03:41:13PM -0600, Jeff Law wrote:
> > On 10/28/19 2:27 PM, Segher Boessenkool wrote:
> > > On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
> > >> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
> > >>> Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?
> > >> The argument that I'd make is that's relatively uncommon (I know, I know
> > >> AIX) that bootstrapping in those environments may well require first
> > >> building something like gcc-9.
> > >>
> > >> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
> > >> we have any good mechanism for making this kind of technical decision
> > >> when there isn't consensus.
> > >
> > > Which GCC version will be required to work as bootstrap compiler?  Will
> > > 4.8.5 be enough?
> > I'd say gcc-9.  What would we gain by making it 4.8 or anything else
> > that old?
>
> That is not a good idea, it will make it much harder to build gcc because
> not everybody has gcc-9 built as a system compiler.
> The previous minimum requirement of 4.1 is perhaps too old now that 4.8 is
> something we could require and gain through that C++11 support, but we
> shouldn't follow Rust with "you can only build it with 6 weeks old previous
> release and nothing else".
> As discussed earlier, we gain most through C++11 support, there is no need
> to jump to C++17 or C++20 as requirement.

Just a quick note.
RHEL/CentOS 7 uses GCC 4.8 as the system compiler.  Requiring a new
compiler to compile GCC 10 will not work for me.
I normally bootstrap GCC 10 and then build a GCC 10 cross compiler.
Having to have an extra compiler inbetween is problematic for me.

Thanks,
Andrew

>
>         Jakub
>

Re: GCC selftest improvements

[Jeff Law]

On 10/28/19 3:52 PM, Andrew Pinski wrote:
> On Mon, Oct 28, 2019 at 2:47 PM Jakub Jelinek <jakub@redhat.com> wrote:
>>
>> On Mon, Oct 28, 2019 at 03:41:13PM -0600, Jeff Law wrote:
>>> On 10/28/19 2:27 PM, Segher Boessenkool wrote:
>>>> On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
>>>>> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
>>>>>> Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?
>>>>> The argument that I'd make is that's relatively uncommon (I know, I know
>>>>> AIX) that bootstrapping in those environments may well require first
>>>>> building something like gcc-9.
>>>>>
>>>>> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
>>>>> we have any good mechanism for making this kind of technical decision
>>>>> when there isn't consensus.
>>>>
>>>> Which GCC version will be required to work as bootstrap compiler?  Will
>>>> 4.8.5 be enough?
>>> I'd say gcc-9.  What would we gain by making it 4.8 or anything else
>>> that old?
>>
>> That is not a good idea, it will make it much harder to build gcc because
>> not everybody has gcc-9 built as a system compiler.
>> The previous minimum requirement of 4.1 is perhaps too old now that 4.8 is
>> something we could require and gain through that C++11 support, but we
>> shouldn't follow Rust with "you can only build it with 6 weeks old previous
>> release and nothing else".
>> As discussed earlier, we gain most through C++11 support, there is no need
>> to jump to C++17 or C++20 as requirement.
> 
> Just a quick note.
> RHEL/CentOS 7 uses GCC 4.8 as the system compiler.  Requiring a new
> compiler to compile GCC 10 will not work for me.
At this point RHEL/CentOS 7 is ancient.  Time to move forward IMHO :-)


I can live with an older compiler, but I'd prefer we move forward as
much as possible.  4.8 is like living in the stone age.

jeff

RE: GCC selftest improvements

[Gabriel Dos Reis via gcc]

| -----Original Message-----
| From: Andrew Pinski <pinskia@gmail.com>
| Sent: Monday, October 28, 2019 2:52 PM
| To: Jakub Jelinek <jakub@redhat.com>
| Cc: Jeff Law <law@redhat.com>; Segher Boessenkool
| <segher@kernel.crashing.org>; Gabriel Dos Reis <gdr@microsoft.com>;
| Andrew Dean <Andrew.Dean@microsoft.com>; David Malcolm
| <dmalcolm@redhat.com>; gcc@gcc.gnu.org; ro@CeBiTec.Uni-Bielefeld.DE;
| mikestump@comcast.net; jason@redhat.com; Jonathan Wakely
| <cxx@kayari.org>
| Subject: Re: GCC selftest improvements
| 
| On Mon, Oct 28, 2019 at 2:47 PM Jakub Jelinek <jakub@redhat.com> wrote:
| >
| > On Mon, Oct 28, 2019 at 03:41:13PM -0600, Jeff Law wrote:
| > > On 10/28/19 2:27 PM, Segher Boessenkool wrote:
| > > > On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
| > > >> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
| > > >>> Jason, Jonathan - is the situation on the terrain really that dire that
| C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped
| from?
| > > >> The argument that I'd make is that's relatively uncommon (I know, I
| know
| > > >> AIX) that bootstrapping in those environments may well require first
| > > >> building something like gcc-9.
| > > >>
| > > >> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
| > > >> we have any good mechanism for making this kind of technical
| decision
| > > >> when there isn't consensus.
| > > >
| > > > Which GCC version will be required to work as bootstrap compiler?  Will
| > > > 4.8.5 be enough?
| > > I'd say gcc-9.  What would we gain by making it 4.8 or anything else
| > > that old?
| >
| > That is not a good idea, it will make it much harder to build gcc because
| > not everybody has gcc-9 built as a system compiler.
| > The previous minimum requirement of 4.1 is perhaps too old now that 4.8
| is
| > something we could require and gain through that C++11 support, but we
| > shouldn't follow Rust with "you can only build it with 6 weeks old previous
| > release and nothing else".
| > As discussed earlier, we gain most through C++11 support, there is no need
| > to jump to C++17 or C++20 as requirement.
| 
| Just a quick note.
| RHEL/CentOS 7 uses GCC 4.8 as the system compiler.  Requiring a new
| compiler to compile GCC 10 will not work for me.
| I normally bootstrap GCC 10 and then build a GCC 10 cross compiler.
| Having to have an extra compiler inbetween is problematic for me.
| 
| Thanks,
| Andrew

I would think C++14 gives you a good compromise, as you have access to key C++11 functionalities with a less crippled constexpr support.

-- Gaby

Re: GCC selftest improvements

[Richard Biener]

On Mon, Oct 28, 2019 at 10:47 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Mon, Oct 28, 2019 at 03:41:13PM -0600, Jeff Law wrote:
> > On 10/28/19 2:27 PM, Segher Boessenkool wrote:
> > > On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
> > >> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
> > >>> Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?
> > >> The argument that I'd make is that's relatively uncommon (I know, I know
> > >> AIX) that bootstrapping in those environments may well require first
> > >> building something like gcc-9.
> > >>
> > >> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
> > >> we have any good mechanism for making this kind of technical decision
> > >> when there isn't consensus.
> > >
> > > Which GCC version will be required to work as bootstrap compiler?  Will
> > > 4.8.5 be enough?
> > I'd say gcc-9.  What would we gain by making it 4.8 or anything else
> > that old?
>
> That is not a good idea, it will make it much harder to build gcc because
> not everybody has gcc-9 built as a system compiler.
> The previous minimum requirement of 4.1 is perhaps too old now that 4.8 is
> something we could require and gain through that C++11 support, but we
> shouldn't follow Rust with "you can only build it with 6 weeks old previous
> release and nothing else".
> As discussed earlier, we gain most through C++11 support, there is no need
> to jump to C++17 or C++20 as requirement.

Yes, I've agreed to raise the requirement to GCC 4.8 which provides
C++11 support.

For convenience we could also provide a configure-time hint if the host compiler
doesn't have C++11 support or is older than 4.8.2 (I think .1 has some issues).
Rather than only running into some obscure errors later on.

Richard.

>         Jakub
>

Re: GCC selftest improvements

[Pedro Alves]

On 10/29/19 8:40 AM, Richard Biener wrote:
> On Mon, Oct 28, 2019 at 10:47 PM Jakub Jelinek <jakub@redhat.com> wrote:
>>

>> As discussed earlier, we gain most through C++11 support, there is no need
>> to jump to C++17 or C++20 as requirement.
> 
> Yes, I've agreed to raise the requirement to GCC 4.8 which provides
> C++11 support.
> 
> For convenience we could also provide a configure-time hint if the host compiler
> doesn't have C++11 support or is older than 4.8.2 (I think .1 has some issues).
> Rather than only running into some obscure errors later on.

FWIW, GDB uses a slightly modified AX_CXX_COMPILE_STDCXX to check for C++11
support at configure time, and add -std=gnu++11 if the necessary, adding nothing
if the compiler supports C++11 or later OOTB (so that you can still access
C++14-or-later features&optimizations conditionally).

 https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/ax_cxx_compile_stdcxx.m4

 https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html

 https://sourceware.org/ml/gdb-patches/2016-10/msg00775.html

In practice, that returns "supports" for GCC 4.8 and above, which is
GDB's minimum requirement.  I'm not sure about 4.8.x patch level.

Thanks,
Pedro Alves

Re: GCC selftest improvements

[Iain Sandoe]

Jeff Law <law@redhat.com> wrote:

> On 10/28/19 2:27 PM, Segher Boessenkool wrote:
>> On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
>>> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
>>>> Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?
>>> The argument that I'd make is that's relatively uncommon (I know, I know
>>> AIX) that bootstrapping in those environments may well require first
>>> building something like gcc-9.
>>> 
>>> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
>>> we have any good mechanism for making this kind of technical decision
>>> when there isn't consensus.
>> 
>> Which GCC version will be required to work as bootstrap compiler?  Will
>> 4.8.5 be enough?
> I'd say gcc-9.  What would we gain by making it 4.8 or anything else
> that old?

We’d have to use something older than 9 on earl(ier) Darwin since 9 will not 
bootstrap with the system-provided tools.

ISTM that using a well-baked stable closed branch would be reasonable?

(so 7.5 or earlier, assuming that the decision is made after 7.5 rolls)

Iain

Re: GCC selftest improvements

[Segher Boessenkool]

On Mon, Oct 28, 2019 at 03:41:13PM -0600, Jeff Law wrote:
> On 10/28/19 2:27 PM, Segher Boessenkool wrote:
> > On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
> >> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
> >>> Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?
> >> The argument that I'd make is that's relatively uncommon (I know, I know
> >> AIX) that bootstrapping in those environments may well require first
> >> building something like gcc-9.
> >>
> >> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
> >> we have any good mechanism for making this kind of technical decision
> >> when there isn't consensus.
> > 
> > Which GCC version will be required to work as bootstrap compiler?  Will
> > 4.8.5 be enough?
> I'd say gcc-9.  What would we gain by making it 4.8 or anything else
> that old?

Many systems do not have a system compiler newer than this *four years old*
one.  GCC 4.8 is the first GCC version that supports all of C++11, which is
the only reason it would be even near acceptable to require something this
*new*.


Segher

Re: GCC selftest improvements

[Richard Biener]

On Mon, Oct 28, 2019 at 11:12 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Mon, Oct 28, 2019 at 03:41:13PM -0600, Jeff Law wrote:
> > On 10/28/19 2:27 PM, Segher Boessenkool wrote:
> > > On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
> > >> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
> > >>> Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from?
> > >> The argument that I'd make is that's relatively uncommon (I know, I know
> > >> AIX) that bootstrapping in those environments may well require first
> > >> building something like gcc-9.
> > >>
> > >> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
> > >> we have any good mechanism for making this kind of technical decision
> > >> when there isn't consensus.
> > >
> > > Which GCC version will be required to work as bootstrap compiler?  Will
> > > 4.8.5 be enough?
> > I'd say gcc-9.  What would we gain by making it 4.8 or anything else
> > that old?
>
> Many systems do not have a system compiler newer than this *four years old*
> one.  GCC 4.8 is the first GCC version that supports all of C++11, which is
> the only reason it would be even near acceptable to require something this
> *new*.

Agreed.  Note we're even shipping new service packs for SLE12 which has that
"ancient" compiler version (OTOH there _is_ a fully supported GCC 9 available
for SLE12 as well).

So, if we want C++11 then fine.  But requiring GCC 9+ isn't going to fly.  IIRC
GCC 6 is first having -std=c++14 by default, but unless there's a compelling
reason to use C++14 in GCC I'd rather not do it at this point.

Removing all the workarounds in the tree we have for GCC 4.[12].x would of
course be nice.

But I have to update the testers that still use GCC 4.1.x as host compiler :P

Richard.

>
> Segher

RE: GCC selftest improvements

[Andrew Dean via gcc]

> > Many systems do not have a system compiler newer than this *four years
> > old* one.  GCC 4.8 is the first GCC version that supports all of
> > C++11, which is the only reason it would be even near acceptable to
> > require something this *new*.
> 
> Agreed.  Note we're even shipping new service packs for SLE12 which has that
> "ancient" compiler version (OTOH there _is_ a fully supported GCC 9 available
> for SLE12 as well).
> 
> So, if we want C++11 then fine.  But requiring GCC 9+ isn't going to fly.  IIRC
> GCC 6 is first having -std=c++14 by default, but unless there's a compelling
> reason to use C++14 in GCC I'd rather not do it at this point.
> 
> Removing all the workarounds in the tree we have for GCC 4.[12].x would of
> course be nice.
> 
> But I have to update the testers that still use GCC 4.1.x as host compiler :P
> 
> Richard.
> 
> >
> > Segher
Richard/Segher: Are we in agreement that we can move forward with updating to c++11 as the minimum version? I have made the simple change locally to modify the flag and verified that I got the exact same test results with/without the change. I can look into the work to add a configuration warning if the compiler doesn't support c++11, but wanted to make sure we are on the same page before doing so.

Re: GCC selftest improvements

[Segher Boessenkool]

On Fri, Nov 22, 2019 at 09:02:05PM +0000, Andrew Dean wrote:
> > > Many systems do not have a system compiler newer than this *four years
> > > old* one.  GCC 4.8 is the first GCC version that supports all of
> > > C++11, which is the only reason it would be even near acceptable to
> > > require something this *new*.
> > 
> > Agreed.  Note we're even shipping new service packs for SLE12 which has that
> > "ancient" compiler version (OTOH there _is_ a fully supported GCC 9 available
> > for SLE12 as well).
> > 
> > So, if we want C++11 then fine.  But requiring GCC 9+ isn't going to fly.  IIRC
> > GCC 6 is first having -std=c++14 by default, but unless there's a compelling
> > reason to use C++14 in GCC I'd rather not do it at this point.
> > 
> > Removing all the workarounds in the tree we have for GCC 4.[12].x would of
> > course be nice.
> > 
> > But I have to update the testers that still use GCC 4.1.x as host compiler :P

> Richard/Segher: Are we in agreement that we can move forward with updating to c++11 as the minimum version? I have made the simple change locally to modify the flag and verified that I got the exact same test results with/without the change. I can look into the work to add a configuration warning if the compiler doesn't support c++11, but wanted to make sure we are on the same page before doing so.

If GCC 4.8.5 works as bootstrap compiler, it is fine with me, and good
progress too.  (Which means 4.8.5 has to work for at least all primary
targets.)

Some targets may have other concerns though.  This needs to be announced
widely, and people given time to protest?


Segher

Re: GCC selftest improvements

[Jakub Jelinek]

On Fri, Nov 22, 2019 at 04:01:43PM -0600, Segher Boessenkool wrote:
> On Fri, Nov 22, 2019 at 09:02:05PM +0000, Andrew Dean wrote:
> > > > Many systems do not have a system compiler newer than this *four years
> > > > old* one.  GCC 4.8 is the first GCC version that supports all of
> > > > C++11, which is the only reason it would be even near acceptable to
> > > > require something this *new*.
> > > 
> > > Agreed.  Note we're even shipping new service packs for SLE12 which has that
> > > "ancient" compiler version (OTOH there _is_ a fully supported GCC 9 available
> > > for SLE12 as well).
> > > 
> > > So, if we want C++11 then fine.  But requiring GCC 9+ isn't going to fly.  IIRC
> > > GCC 6 is first having -std=c++14 by default, but unless there's a compelling
> > > reason to use C++14 in GCC I'd rather not do it at this point.
> > > 
> > > Removing all the workarounds in the tree we have for GCC 4.[12].x would of
> > > course be nice.
> > > 
> > > But I have to update the testers that still use GCC 4.1.x as host compiler :P
> 
> > Richard/Segher: Are we in agreement that we can move forward with updating to c++11 as the minimum version? I have made the simple change locally to modify the flag and verified that I got the exact same test results with/without the change. I can look into the work to add a configuration warning if the compiler doesn't support c++11, but wanted to make sure we are on the same page before doing so.
> 
> If GCC 4.8.5 works as bootstrap compiler, it is fine with me, and good
> progress too.  (Which means 4.8.5 has to work for at least all primary
> targets.)

What would be the advantage of bumping the requirement now as opposed to at
the start of next stage 1 though?  We should be fixing bugs now, not
introduce new features nor do code refactoring.

	Jakub

Re: GCC selftest improvements

[Segher Boessenkool]

On Fri, Nov 22, 2019 at 11:36:18PM +0100, Jakub Jelinek wrote:
> On Fri, Nov 22, 2019 at 04:01:43PM -0600, Segher Boessenkool wrote:
> > On Fri, Nov 22, 2019 at 09:02:05PM +0000, Andrew Dean wrote:
> > > > > Many systems do not have a system compiler newer than this *four years
> > > > > old* one.  GCC 4.8 is the first GCC version that supports all of
> > > > > C++11, which is the only reason it would be even near acceptable to
> > > > > require something this *new*.
> > > > 
> > > > Agreed.  Note we're even shipping new service packs for SLE12 which has that
> > > > "ancient" compiler version (OTOH there _is_ a fully supported GCC 9 available
> > > > for SLE12 as well).
> > > > 
> > > > So, if we want C++11 then fine.  But requiring GCC 9+ isn't going to fly.  IIRC
> > > > GCC 6 is first having -std=c++14 by default, but unless there's a compelling
> > > > reason to use C++14 in GCC I'd rather not do it at this point.
> > > > 
> > > > Removing all the workarounds in the tree we have for GCC 4.[12].x would of
> > > > course be nice.
> > > > 
> > > > But I have to update the testers that still use GCC 4.1.x as host compiler :P
> > 
> > > Richard/Segher: Are we in agreement that we can move forward with updating to c++11 as the minimum version? I have made the simple change locally to modify the flag and verified that I got the exact same test results with/without the change. I can look into the work to add a configuration warning if the compiler doesn't support c++11, but wanted to make sure we are on the same page before doing so.
> > 
> > If GCC 4.8.5 works as bootstrap compiler, it is fine with me, and good
> > progress too.  (Which means 4.8.5 has to work for at least all primary
> > targets.)
> 
> What would be the advantage of bumping the requirement now as opposed to at
> the start of next stage 1 though?  We should be fixing bugs now, not
> introduce new features nor do code refactoring.

Oh, I meant for GCC 11, of course.  I thought we all agreed on that.


Segher

Re: GCC selftest improvements

[Jeff Law]

On 11/22/19 4:41 PM, Segher Boessenkool wrote:
> On Fri, Nov 22, 2019 at 11:36:18PM +0100, Jakub Jelinek wrote:
>> On Fri, Nov 22, 2019 at 04:01:43PM -0600, Segher Boessenkool wrote:
>>> On Fri, Nov 22, 2019 at 09:02:05PM +0000, Andrew Dean wrote:
>>>>>> Many systems do not have a system compiler newer than this *four years
>>>>>> old* one.  GCC 4.8 is the first GCC version that supports all of
>>>>>> C++11, which is the only reason it would be even near acceptable to
>>>>>> require something this *new*.
>>>>>
>>>>> Agreed.  Note we're even shipping new service packs for SLE12 which has that
>>>>> "ancient" compiler version (OTOH there _is_ a fully supported GCC 9 available
>>>>> for SLE12 as well).
>>>>>
>>>>> So, if we want C++11 then fine.  But requiring GCC 9+ isn't going to fly.  IIRC
>>>>> GCC 6 is first having -std=c++14 by default, but unless there's a compelling
>>>>> reason to use C++14 in GCC I'd rather not do it at this point.
>>>>>
>>>>> Removing all the workarounds in the tree we have for GCC 4.[12].x would of
>>>>> course be nice.
>>>>>
>>>>> But I have to update the testers that still use GCC 4.1.x as host compiler :P
>>>
>>>> Richard/Segher: Are we in agreement that we can move forward with updating to c++11 as the minimum version? I have made the simple change locally to modify the flag and verified that I got the exact same test results with/without the change. I can look into the work to add a configuration warning if the compiler doesn't support c++11, but wanted to make sure we are on the same page before doing so.
>>>
>>> If GCC 4.8.5 works as bootstrap compiler, it is fine with me, and good
>>> progress too.  (Which means 4.8.5 has to work for at least all primary
>>> targets.)
>>
>> What would be the advantage of bumping the requirement now as opposed to at
>> the start of next stage 1 though?  We should be fixing bugs now, not
>> introduce new features nor do code refactoring.
> 
> Oh, I meant for GCC 11, of course.  I thought we all agreed on that.
Yea, I don't see that stepping forward for gcc-10 really brings us
anything.  We're past stage1 and thus Andrew's work would naturally
target gcc-11.

So the advice I'd give Andrew is go ahead with using C++11 as needed.
However, also try to be sensible in terms of what features you use :-)

jeff

Re: GCC selftest improvements

[Nicholas Krause]

On 11/23/19 11:33 AM, Jeff Law wrote:
> On 11/22/19 4:41 PM, Segher Boessenkool wrote:
>> On Fri, Nov 22, 2019 at 11:36:18PM +0100, Jakub Jelinek wrote:
>>> On Fri, Nov 22, 2019 at 04:01:43PM -0600, Segher Boessenkool wrote:
>>>> On Fri, Nov 22, 2019 at 09:02:05PM +0000, Andrew Dean wrote:
>>>>>>> Many systems do not have a system compiler newer than this *four years
>>>>>>> old* one.  GCC 4.8 is the first GCC version that supports all of
>>>>>>> C++11, which is the only reason it would be even near acceptable to
>>>>>>> require something this *new*.
>>>>>> Agreed.  Note we're even shipping new service packs for SLE12 which has that
>>>>>> "ancient" compiler version (OTOH there _is_ a fully supported GCC 9 available
>>>>>> for SLE12 as well).
>>>>>>
>>>>>> So, if we want C++11 then fine.  But requiring GCC 9+ isn't going to fly.  IIRC
>>>>>> GCC 6 is first having -std=c++14 by default, but unless there's a compelling
>>>>>> reason to use C++14 in GCC I'd rather not do it at this point.
>>>>>>
>>>>>> Removing all the workarounds in the tree we have for GCC 4.[12].x would of
>>>>>> course be nice.
>>>>>>
>>>>>> But I have to update the testers that still use GCC 4.1.x as host compiler :P
>>>>> Richard/Segher: Are we in agreement that we can move forward with updating to c++11 as the minimum version? I have made the simple change locally to modify the flag and verified that I got the exact same test results with/without the change. I can look into the work to add a configuration warning if the compiler doesn't support c++11, but wanted to make sure we are on the same page before doing so.
>>>> If GCC 4.8.5 works as bootstrap compiler, it is fine with me, and good
>>>> progress too.  (Which means 4.8.5 has to work for at least all primary
>>>> targets.)
>>> What would be the advantage of bumping the requirement now as opposed to at
>>> the start of next stage 1 though?  We should be fixing bugs now, not
>>> introduce new features nor do code refactoring.
>> Oh, I meant for GCC 11, of course.  I thought we all agreed on that.
> Yea, I don't see that stepping forward for gcc-10 really brings us
> anything.  We're past stage1 and thus Andrew's work would naturally
> target gcc-11.
>
> So the advice I'd give Andrew is go ahead with using C++11 as needed.
> However, also try to be sensible in terms of what features you use :-)
>
> jeff
CCing myself to the conversation as the original idea contributor
for adding support for C++11.

Thanks,
Nick
>

Re: GCC selftest improvements

[Mike Stump]

On Oct 28, 2019, at 12:40 PM, Jeff Law <law@redhat.com> wrote:
> I'd really like to see us move to C++11 or beyond.  Sadly, I don't think
> we have any good mechanism for making this kind of technical decision
> when there isn't consensus.

I'll just point out that we do have good mechanisms in place.  Consensus building is a nice way of doing things, but, when that fails, we can punt to a well established reviewer to just make a decision, because sometimes a made decision is better than failing to make a decision, which, itself, is a decision.  It that should fail for any reason, anyone should feel free to punt to the SC.  Generally we don't use them this way, but, I think it's reasonable to do this if all the maintainers are shy about this or need guidance.

For example, the current policy is to pick the minimum gcc version of all the current LTS release of all the distributions/OSes.  I could propose this be the policy to the SC, then they could, if they wanted to, agree with the policy, then we can document the policy, and then a reviewer can approve a doc patch to say that gcc X or newer is required, whenever the new X is the oldest among the then current set of distributions/OSes.  The policy drives expectations, and drives approvals to bump.  Now, that's just a recommendation.  A reviewer might have a reason to not bump the tools, and that's ok as well.  No reviewer should feel bad, approving a bump when that bump follows the policy however.

If I apply the current policy, [  checking around ] My 18.04 has 7.4 in it.  Centos 8 has 8.2.  It would seem that a bump to 7.4 should be fine, now.  I didn't look at other distributions, but we can go through the list, and on the basis of what version is in the current LTS/OS, contemplate the bump the the minimum of all of them.  That's basically the status quo policy.

Now, people do like to hold onto old OSes and old machines.  And we cater to them by having old releases that can drop onto their system and just run.  For example, I have a 14.04 machine, that's still awaiting 20.04 to upgrade to, but thats because I want to cater even to very old releases (all LTS releases that are not EOL), cause doing this is very cheap.  I manage this by dropping a gcc 9 onto the box so that I have a known, not that old compiler.  Presto, all my software can now use gcc 9 features and not worry about it.

So, I'd propose bumping the minimum to 7.4 if people want to update.  People can comment what release fedora, arch, SUSE and so on have.  Since 7.4 has c++17 in it (non-default), accepting patches that turn on c++17 in that compiler isn't unreasonable, but that's orthogonal to the version bump.  My old Apple has c++17 on it.  Don't have a windows box, but google seems to suggest that their tools support c++17.

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.