LCOV of current GCC
Hello. I've been working on some patches for GCOV and lcov was of my test scenarios. I'm sending link to static HTML pages made by the tool which are recorded for GCC (w/o bootstrap) build + running test-suite on x86_64-linux-gnu. I'm planning to set up a periodic build of that that will eventually rsync content to a public website: I guess it can be interesting for instance to see which folding branches are not used, or which files (functionality) is basically not much tested via the testsuite. https://drive.google.com/open?id=0B0pisUJ80pO1X0s3eEpuQ25GTG8 P.S. I've noticed David fixed doxygen of the project, I can rsync also that to public website. Martin
Re: LCOV of current GCC
On Fri, Apr 28, 2017 at 11:07 AM, Martin Liška wrote: > Hello. > > I've been working on some patches for GCOV and lcov was of my test scenarios. > I'm sending link to static HTML pages made by the tool which are recorded > for GCC (w/o bootstrap) build + running test-suite on x86_64-linux-gnu. > I'm planning to set up a periodic build of that that will eventually rsync > content to a public website: > > I guess it can be interesting for instance to see which folding branches are > not used, or which files (functionality) is basically not much tested via > the testsuite. > > https://drive.google.com/open?id=0B0pisUJ80pO1X0s3eEpuQ25GTG8 > > P.S. I've noticed David fixed doxygen of the project, I can rsync also that > to public website. Nice! Results look better than anticipated ;) Richard. > Martin
Doxygen for GCC
Hello. There are couple of pending patches: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01478.html Using the patches, we can generate following Doxygen 'documentation': https://drive.google.com/open?id=0B0pisUJ80pO1dmhldmo3R3JHLWc I'm planning to periodically build it and rsync to a public website. I guess, sometimes it can be handy. Martin
Re: [C++ Patch] Remove is_auto_or_concept, etc (Was: Re: [C++, concepts] Two slightly obscure pt.c functions?)
On 04/27/2017 02:02 PM, Paolo Carlini wrote: ... replying to myself, in practice we could do the below, which certainly passes testing, and in fact now seems to me even more obvious than I thought a couple of days ago... I'm insufficiently conceptified to know whether this is safe (but lack of test failure is promising). nathan -- Nathan Sidwell
Second GCC 7.1 Release Candidate available from gcc.gnu.org
The second release candidate for GCC 7.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/7.0.1-RC-20170428 and shortly its mirrors. It has been generated from SVN revision 247368. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 7.1 on Tuesday, May 2nd.
Re: Ada gcc compiler for ia64-hp-openvms
On Thu, Apr 27, 2017 at 10:55 AM, David SAUVAGE - AdaLabs Ltd wrote: > > Dear GCC Steering Committee, > > I am David, founder of AdaLabs Ltd, a software engineering startup > having expertise in Ada programming language technologies. As a summary, > we would like to know if gcc has interest in an assignment of copyright > to FSF from our work. We are not used to this process, and are kindly > soliciting your support on this task. Our work is about Ada compiler > support on GCC for OpenVMS. > > AdaLabs Ltd (http://adalabs.com) and PIA-SOFER SARL > (http://pia-sofer.fr) have worked hard to make Ada available again on > OpenVMs using GCC (ia64-hp-openvms). Both entities share ownership, > while AdaLabs is also the author of the work. > > Our work is based on gcc-4.7.4, and consists in building a gcc compiler > for openvms ia64 (through native, cross and canadian build, starting > from x86_64-linux-gnu to finally reach ia64-hp-openvms). The > modifications are of two flavours: > - patches to make the builds successful (in native, cross and canadian > builds) > - patches/backports to implement Ada/VMS related features, that are > present in gcc version after gcc-4.7.4 (in native, cross and canadian > builds). > > In the case you are interested in our copyright assignment proposal, we > would be pleased to continue this process. > > In the case you are not interested in our copyright assignment proposal, > we would be pleased if you could advise us on the best way to make our > work available to the GNU/FSF community, especially concerning the > licenses and copyrights management. > > I am at your disposal concerning any information you may need to take a > stand concerning this proposal. Hi, David The GCC Community always is open to considering patches to support new languages, new targets and new features. When you say that the work is based on GCC 4.7.4, does that mean that the patches are relative to GCC 4.7.4, as opposed to the current development version of GCC? GCC only accepts patches relative to the current development sources. Patches for bug fixes can be considered for backporting to an actively maintained branch, but GCC does not accept patches for completely new features to a release branch. Also, GCC 4.7 initially was released 5 years ago and no longer accepts patches. Does the offer include continued support and maintenance of Ada/VMS to ensure that it continues to function? The GCC community requires someone to assume responsibility for the continued function of the new feature. Can you clarify some of the details of the offer? Thanks, David
Re: LCOV of current GCC
On 04/28/2017 03:38 AM, Richard Biener wrote: On Fri, Apr 28, 2017 at 11:07 AM, Martin Liška wrote: Hello. I've been working on some patches for GCOV and lcov was of my test scenarios. I'm sending link to static HTML pages made by the tool which are recorded for GCC (w/o bootstrap) build + running test-suite on x86_64-linux-gnu. I'm planning to set up a periodic build of that that will eventually rsync content to a public website: I guess it can be interesting for instance to see which folding branches are not used, or which files (functionality) is basically not much tested via the testsuite. https://drive.google.com/open?id=0B0pisUJ80pO1X0s3eEpuQ25GTG8 P.S. I've noticed David fixed doxygen of the project, I can rsync also that to public website. Nice! Results look better than anticipated ;) I did some similar work a few years back. Martin's results are comparable to mine. Interestingly enough the 70-80% coverage we see for GCC is a "sweet spot" in that several of the ancillary tools I tested were in the same overall range. jeff
Re: LCOV of current GCC
On Fri, 2017-04-28 at 11:38 +0200, Richard Biener wrote: > On Fri, Apr 28, 2017 at 11:07 AM, Martin Liška > wrote: > > Hello. > > > > I've been working on some patches for GCOV and lcov was of my test > > scenarios. > > I'm sending link to static HTML pages made by the tool which are > > recorded > > for GCC (w/o bootstrap) build + running test-suite on x86_64-linux > > -gnu. > > I'm planning to set up a periodic build of that that will > > eventually rsync > > content to a public website: > > > > I guess it can be interesting for instance to see which folding > > branches are > > not used, or which files (functionality) is basically not much > > tested via > > the testsuite. > > > > https://drive.google.com/open?id=0B0pisUJ80pO1X0s3eEpuQ25GTG8 > > > > P.S. I've noticed David fixed doxygen of the project, I can rsync > > also that > > to public website. > > Nice! Results look better than anticipated ;) > > Richard. > > > Martin Excellent; thanks. For your periodic builds, please can you add "jit" to the enabled languages (it will also need --enable-host-shared). Would be nice to add libiberty and libcpp to this, but maybe that needs extra work? Dave
Re: LCOV of current GCC
On Fri, 28 Apr 2017, Jeff Law wrote: > I did some similar work a few years back. Martin's results are comparable to > mine. Interestingly enough the 70-80% coverage we see for GCC is a "sweet > spot" in that several of the ancillary tools I tested were in the same overall > range. My observation from looking at some of the C front-end results is that many of the coverage omissions are from features only used / supported on certain architectures, e.g. address spaces and fixed point (though actually there are address spaces on x86, but maybe not tests covering much of the generic address space support). -- Joseph S. Myers jos...@codesourcery.com
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
Hi Andrew, On Wed, Apr 26, 2017 at 10:18:55AM +0100, Andrew Jenner wrote: > On 13/03/2017 18:01, Andrew Jenner wrote: > >I volunteer to be the point of contact for the SPE port. > > > >Over here at CodeSourcery/Mentor Embedded, we have a strong interest in > >SPE *not* being deprecated (we actively ship toolchain products with SPE > >multilibs, and have customers for which these are important). We are > >therefore volunteering resources (specifically, me) to maintain SPE > >upstream as well. > > Ping. > > My understanding is that I need to be appointed by the steering > committee to become a maintainer, but I have not yet heard anything from > them. > > Either way, I will work on cleaning up the SPE test results and getting > some patches sent upstream to make sure this part of the port is in good > shape. Here's the sequence of things that should happen: 1) Test results are posted to gcc-testresults@, ideally regularly. Without test results no one can know if they break things. 2) The port has to be created. I volunteered to do that. This can start soon after the GCC 7 release. It will be hard to do without having test results. We also still have to agree on the target triples for the new port. If you have any thoughts on this, I'd love to hear them. 3) The port has to be accepted by the steering committee, and you appointed the maintainer. This should be just a formality after 1) and 2). Segher
