[PATCH] Clean up references to Subversion in documentation sources.
tion on customising the - output of svn diff. + latest version of GNU diff. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml index 2b05ff6601a..cf5722377a6 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml @@ -18,7 +18,7 @@ This status table is based on the table of contents of ISO/IEC 14882:2003. -This page describes the C++ support in mainline GCC SVN, not in any +This page describes the C++ support in mainline GCC, not in any particular release. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml index 6f3551ff65d..9d2de532f3d 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml @@ -27,7 +27,7 @@ presence of the required flag. -This page describes the C++11 support in mainline GCC SVN, not in any +This page describes the C++11 support in mainline GCC, not in any particular release. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml index a33b4ec1611..a0b900d9a12 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml @@ -20,7 +20,7 @@ presence of the required flag. -This page describes the C++14 and library TS support in mainline GCC SVN, +This page describes the C++14 and library TS support in mainline GCC, not in any particular release. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml index d154d725391..188c3f88551 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml @@ -20,7 +20,7 @@ presence of the required flag. -This section describes the C++17 and library TS support in mainline GCC SVN, +This section describes the C++17 and library TS support in mainline GCC, not in any particular release. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml index a8f0ac294f3..17f28887119 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml @@ -20,7 +20,7 @@ presence of the required flag. -This section describes the C++20 and library TS support in mainline GCC SVN, +This section describes the C++20 and library TS support in mainline GCC, not in any particular release. diff --git a/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml b/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml index 32ad20a2fb2..b9e415d21ac 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml @@ -22,7 +22,7 @@ In this implementation the header names are prefixed by -This page describes the TR1 support in mainline GCC SVN, not in any particular +This page describes the TR1 support in mainline GCC, not in any particular release. diff --git a/libstdc++-v3/doc/xml/manual/status_cxxtr24733.xml b/libstdc++-v3/doc/xml/manual/status_cxxtr24733.xml index e8d445116a2..92d892da8ac 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxxtr24733.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxxtr24733.xml @@ -16,7 +16,7 @@ decimal floating-point arithmetic -This page describes the TR 24733 support in mainline GCC SVN, not in any +This page describes the TR 24733 support in mainline GCC, not in any particular release. -- 2.20.1 -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: [PATCH] Clean up references to Subversion in documentation sources.
Joseph Myers : > I think you'll need to commit this for Eric (using --author= to set the > git author, whenever you commit a patch for someone else). The libstdc++ > maintainers can probably handle regenerating the HTML version of the > libstdc++ documentation. I'm hesitant to request push access this soon, but...you don't seem to have an MR capability, and I have some other housekeeping/documentation patches in mind. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: [PATCH] Clean up references to Subversion in documentation sources.
Jonathan Wakely : > Email the patches to gcc-patches@gcc.gnu.org, that's how things get > merged. > > We're not looking to change any workflows now. Roger that. Once the dust from the conversion has settled, though, there is a related issue I intend to bring up on the main list. You've only collected about 60% of the potential benefits from git by adopting git itself. The other 40% would come from moving to to one of the modern git-centric forges like GitHub or GitLab. I'm as old-school as any of you guys, so take me seriously when I say these are not popular for merely faddish reasns. The integration of repository management, issue tracking, and continuous integration they offer really does offer a major step up in productivity and auditability. I *will* be nudging the GCC project community to think about this. -- http://www.catb.org/~esr/";>Eric S. Raymond
[PATCH] Document how to track whether you have a good build.
Document what I was told on #gcc --- gcc/doc/install.texi | 8 1 file changed, 8 insertions(+) diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi index 643f3bb311f..12a6db1666a 100644 --- a/gcc/doc/install.texi +++ b/gcc/doc/install.texi @@ -3039,6 +3039,14 @@ current time the testing harness does not allow fine grained control over whether or not a test is expected to fail. This problem should be fixed in future releases. +At present (Jan 2020) you can expect routine failures in quality tests +related to the optimizer even on first-tier platforms such as x86_64. +Until the test suite behavior is improved, an effective way to proceed +is to run contrib/test_summary immediately after first build on a +clean tree, save the output, and treat that as a correctness baseline. + +After making your changes, run contrib/test_summary again and look for +regressions - that is, FAIL results where it was previously PASS. @section Submitting test results -- 2.20.1
State of the reposurgeon conversion
First, my apologies for not responding five days ago. Joseph's mail issued as I was transitioning to a new machine and the day before I spent some hours in the ER of my local hospital, and I missed it in the confusion. In case you missed it on the main list, git-svn is *not safe* for histories within even three orders of magnitude of ggc's complexity. See http://esr.ibiblio.org/?p=6778 for the PSA I wrote last time I heard about an attempt to use it for an important conversion. Joseph Myers wrote: >ESR, can you give an update on the status of the conversion with >reposurgeon? You said "another serious attack on the repository >conversion is probably about two months out" in ><https://gcc.gnu.org/ml/gcc/2018-12/msg00112.html>. Is it on target to be >done by the time of the GNU Tools Cauldron in Montreal in September? I'd say that's about a 65% chance. Better than even, not high enough for me to make any hard promises. I just took delivery of a newer, faster surgical machine - an AMD Threadripper cranking 4.2Ghz on 64 hardware threads (thank you, System76 for the donation). I upgraded specifically to tackle the GCC problem. Early benchmarks on repocutter-in-Go suggest I'll get at least a 15x speedup relative to the Python version of reposurgeon, possibly rather more. That should reduce test conversion cycles to less than an hour, which ought to be fast enough that I can converge on a solution in reasonable time. The main source of uncertainty here is how long it will take me to finish the Go translation of reposurgeon. Once that's done I don't expect a finished conversion to take more than a couple of weeks to produce. The good news is the translation is now over 90% done; the bad news is that the part still pending includes the part you really care about, the Subversion dump interpreter. I realize this may not be the best place to ask, but the most effective way to speed things up would be to second me somebody with Go skills to help with finishing and debugging the translation. The blocker is not Go knowledge per se, it's the intrinsic complexity of the code I'm translating. Even with my skills and domain expertise this is a tough job. I will further add that a really motivated expert C programmer would do for the help. Go is an easy enough transition for a C expert that it would be practical to learn the language while assisting with this. >And, could you bring git://thyrsus.com/repositories/gcc-conversion.git up >to date with changes since Jan 2018, or push the latest version of that >repository to some other public hosting location? Done. https://gitlab.com/esr/gcc-conversion Interested parties here can have dev permissions if they like. > That repository >represents what I consider the collaboratively built consensus on such >things as the desired author map (including handling of the ambiguous >author name), which directories represent branches and tags, and what tags >should be kept or removed - but building up such a consensus and keeping >it up to date over time (for new committers etc.) requires that the public >repository actually reflects the latest version of the conversion >machinery, day by day as the consensus develops. Review of that >repository will be important for reviewing the details of whether the >conversion is being done as desired - the details of the machinery will >help suggest things to spot-check in a converted repository. I concur totally with that philosophy. (About that ER visit: I'll be OK. I have an injury called an osteochondral lesion in my right angle resulting from an ankle sprain in kung fu class, with arthroscopic surgery scheduled to correct it in June. On the 15th my ankle gave out while I was cooking breakfast; I fell down and hit my head on a chair leg. A short but expensive visit to the ER later I had three staples in my scalp and an MRI showing no brain damage. That could have gone far worse; joke about this if you like but we should all be thankful that I happen to have a rather thicker, tougher skull than average.) -- http://www.catb.org/~esr/";>Eric S. Raymond
