Re: Second GCC 14.1 Release Candidate available from gcc.gnu.org
Bootstrapping the following configuration (with LRA enabled) looks good for ia64, too: ``` CFLAGS="-O2 -fPIC" \ CXXFLAGS="-O2 -fPIC" \ ../configure --prefix=/usr \ --enable-obsolete \ --libdir=/usr/lib \ --mandir=/usr/man \ --infodir=/usr/info \ --enable-shared \ --enable-bootstrap \ --enable-languages=c,c++,fortran \ --enable-threads=posix \ --enable-checking=release \ --with-system-zlib \ --enable-libstdcxx-dual-abi \ --with-default-libstdcxx-abi=new \ --disable-libstdcxx-pch \ --disable-libunwind-exceptions \ --enable-__cxa_atexit \ --disable-libssp \ --enable-gnu-unique-object \ --enable-plugin \ --disable-lto \ --disable-install-libiberty \ --disable-werror \ --with-gnu-ld \ --with-isl \ --verbose \ --with-arch-directory=ia64 \ --disable-gtktest \ --enable-clocale=gnu \ --disable-multilib \ --target=ia64-t2-linux-gnu \ --build=ia64-t2-linux-gnu \ --host=ia64-t2-linux-gnu ``` The addition of fortran to the enabled languages adds about 20 mins to the bootstrap timings mentioned on [1] for the same machine (and just c and c++): ``` time make -j9 bootstrap-lean [...] real295m51.942s user2072m18.957s sys29m0.798s ``` [1]: https://gcc.gnu.org/pipermail/gcc/2024-May/243870.html Running the testsuites for gcc and g++ (this time with `-j4` for each, dropping the time needed for each down to about 114 mins from 4.5 to 5 hours when each testsuite only uses one hardware thread) shows some differences in test results compared to the results with RC1: ``` === gcc Summary === gcc-14 RC2 RC1 # of expected passes133497 134528 # of unexpected failures916 909 # of unexpected successes 18 18 # of expected failures 13541365 # of unresolved testcases 20 20 # of unsupported tests 30333033 === g++ Summary === gcc-14 RC2 RC1 # of expected passes246657 247363 # of unexpected failures213 200 # of expected failures 25932595 # of unresolved testcases 5 5 # of unsupported tests 11497 11496 ``` For RC2 the results are aggregated from the four separate results for each testsuite. As the failures do not increase by the same amount as the number of expect passes decreased, I assume this is "only" an effect of using multiple make jobs. This is "similar" for libgomp (duration around 60 mins, with `j4`, around 51 mins w/o `-j`), though the number of expected passes more than doubles for the parallel case compared to the serial case, so maybe aggregating the results for this testsuite is not correct. I don't have enough comparison data yet for the other testsuites I ran: * gfortran (duration around 100 mins, with `j4`) * libatomic (duration 12 seconds, w/o `-j` ;-) ) * libstdc++ (duration around 5 hours, with `-j4`) ...to be able to tell, if the results are any worse or better. But I at least figured out that adding `-j4` for the libstdc++ testsuite makes it complete in just a little longer than 5 hours instead of no completion in more than 10 hours on the same hardware mentioned in [1]. This also means that the "whole" testsuite for the configuration above might be able to complete in around 6 hours if gcc, g++ and gfortran are done in parallel to libstdc++ and libgomp (after libstdc++ has finished) - IINM. Cheers, Frank On 03.05.24 22:57, Jakub Jelinek via Gcc wrote: The second release candidate for GCC 14.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/ ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/ and shortly its mirrors. It has been generated from git commit r14-10165-g3b4d6b6ecd79df790. The https://gcc.gnu.org/PR114935 bug has been reported and determined a release blocker, so we'd like to get extra testing on it prior to the release. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, we'd still like to release 14.1 on Tuesday, May 7th.
Re: Second GCC 14.1 Release Candidate available from gcc.gnu.org
> On 3 May 2024, at 21:57, Jakub Jelinek via Gcc wrote: > > The second release candidate for GCC 14.1 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/ > ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/ > > and shortly its mirrors. It has been generated from git commit > r14-10165-g3b4d6b6ecd79df790. > > The https://gcc.gnu.org/PR114935 bug has been reported and determined > a release blocker, so we'd like to get extra testing on it prior to > the release. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux. Please test it and report any issues to bugzilla. > > If all goes well, we'd still like to release 14.1 on Tuesday, May 7th. Looks the same as rc1 on Darwin, thanks, Iain
Re: Updated Sourceware infrastructure plans
On Sun, May 05, 2024 at 08:22:12 +0300, Benson Muite wrote: > On 04/05/2024 22.56, Ben Boeckel via Overseers wrote: > > As a fellow FOSS maintainer I definitely appreciate the benefit of being > > email-based (`mutt` is far better at wrangling notifications from > > umpteen places than…well basically any website is at even their own), > > but as a *contributor* it is utterly opaque. It's not always clear if my > > patch has been seen, if it is waiting on maintainer time, or for me to > > do something. After one review, what is the courtesy time before pushing > > a new patchset to avoid a review "crossing in the night" as I push more > > patches? Did I get everyone that commented on the patch the first time > > in the Cc list properly? Is a discussion considered resolved (FWIW, > > Github is annoying with its conversation resolution behavior IMO; > > GitLab's explicit closing is much better). Has it been merged? To the > > right place? And that's for patches I author; figuring out the status of > > patches I'm interested in but not the author of is even harder. A forge > > surfaces a lot of this information pretty well and, to me, GitLab at > > least offers usable enough email messages (e.g., discussions on threads > > will thread in email too) that the public tracking of such things is far > > more useful on the whole. > > This is an area that also needs standardization of important > functionality. Some method of archiving the content is also helpful - > email does this well but typically does not offer dashboard. Sourcehut > makes reading threads using the web interface very easy. The other thing that email makes difficult to do: jump in on an existing discussion without having been subscribed previously. I mean, I know how to tell `mutt` to set an `In-Reply-To` header and munge a proper reply by hand once I find a `Message-Id` (though a fully proper `References` header is usually way too much work to be worth it), but this is not something I expect others to be able to easily perform. > Web interfaces are difficult to automate, but friendlier for occasional > use and encouraging new contributions. Tools separate from the version > control system such as Gerrit, Phabricator, Rhode Code and Review Board > also enable discussion management and overview. Note that forges tend to have very rich APIs. It's certainly not as easy as clicking around manually for one-off tasks or setting up a shell pipeline to process some emails, but building automation isn't impossible. --Ben
Tests of gcc development beyond its testsuite (in this case, for gfortran)
I have now, for some time, ran LAPACK's test programs on my gcc/gfortran builds on both on the x86_64-linux-gnu architecture, as well as the aarch64-linux-gnu one (see, e.g., http://moene.org/~toon/lapack-amd64-gfortran13-O3). The results are rather alarming - this is r15-202 for aarch64 vs r15-204 for x86_64 (compiled with -O3): diff lapack-amd64-gfortran15-O3 lapack-aarch64-gfortran15-O3 3892,3895c3928,3931 < REAL 1327023 0 (0.000%)0 (0.000%) < DOUBLE PRECISION 1300917 6 (0.000%)0 (0.000%) < COMPLEX786775 0 (0.000%)0 (0.000%) < COMPLEX16 787842 0 (0.000%)0 (0.000%) --- > REAL 1317063 71 (0.005%)0 (0.000%) > DOUBLE PRECISION 1318331 54 (0.004%)4 (0.000%) > COMPLEX767023 390 (0.051%)0 (0.000%) > COMPLEX16 772338 305 (0.039%)0 (0.000%) 3897c3933 < --> ALL PRECISIONS 4202557 6 (0.000%)0 (0.000%) --- > --> ALL PRECISIONS 4174755 820 (0.020%)4 (0.000%) Note the excessive exceeding the threshold for errors on the aarch64 side (>). Of course, this is only an excerpt of the full log file - there is more information in it to zoom in on the errors on the aarch64 side (note that the x86_64 side is not faultless). Is there a way to pass this information to our websites, so that we do not "forget" this - or in the alternative, follow the progress in solving this ? Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On Mon, May 6, 2024 at 2:27 PM Toon Moene wrote: > > I have now, for some time, ran LAPACK's test programs on my gcc/gfortran > builds on both on the x86_64-linux-gnu architecture, as well as the > aarch64-linux-gnu one (see, e.g., > http://moene.org/~toon/lapack-amd64-gfortran13-O3). > > The results are rather alarming - this is r15-202 for aarch64 vs r15-204 > for x86_64 (compiled with -O3): Did you test x86_64 with -march=native (or with -mfma) or just -O3? The reason why I am asking is aarch64 includes FMA by default while x86_64 does not. Most recent x86_64 includes an FMA instruction but since the base ISA does not include it, it is not enabled by default. I am suspect the aarch64 "excessive exceeding the threshold for errors" are all caused by the more use of FMA rather than anything else. Thanks, Andrew Pinski > > diff lapack-amd64-gfortran15-O3 lapack-aarch64-gfortran15-O3 > > 3892,3895c3928,3931 > < REAL 1327023 0 (0.000%)0 > (0.000%) > < DOUBLE PRECISION 1300917 6 (0.000%)0 > (0.000%) > < COMPLEX 786775 0 (0.000%)0 > (0.000%) > < COMPLEX16 787842 0 (0.000%)0 > (0.000%) > --- > > REAL 1317063 71 (0.005%)0 > (0.000%) > > DOUBLE PRECISION 1318331 54 (0.004%)4 > (0.000%) > > COMPLEX 767023 390 (0.051%)0 > (0.000%) > > COMPLEX16772338 305 (0.039%)0 > (0.000%) > 3897c3933 > < --> ALL PRECISIONS4202557 6 (0.000%)0 > (0.000%) > --- > > --> ALL PRECISIONS 4174755 820 (0.020%)4 > (0.000%) > > Note the excessive exceeding the threshold for errors on the aarch64 > side (>). > > Of course, this is only an excerpt of the full log file - there is more > information in it to zoom in on the errors on the aarch64 side (note > that the x86_64 side is not faultless). > > Is there a way to pass this information to our websites, so that we do > not "forget" this - or in the alternative, follow the progress in > solving this ? > > Kind regards, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On 5/6/24 23:32, Andrew Pinski wrote: Did you test x86_64 with -march=native (or with -mfma) or just -O3? The reason why I am asking is aarch64 includes FMA by default while x86_64 does not. Most recent x86_64 includes an FMA instruction but since the base ISA does not include it, it is not enabled by default. I am suspect the aarch64 "excessive exceeding the threshold for errors" are all caused by the more use of FMA rather than anything else. Aah, I forgot to include that tidbit, because its readily apparent from the full logs - I compiled with *just* -O3. Thanks, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On 5/6/24 23:35, Toon Moene wrote: On 5/6/24 23:32, Andrew Pinski wrote: Did you test x86_64 with -march=native (or with -mfma) or just -O3? The reason why I am asking is aarch64 includes FMA by default while x86_64 does not. Most recent x86_64 includes an FMA instruction but since the base ISA does not include it, it is not enabled by default. I am suspect the aarch64 "excessive exceeding the threshold for errors" are all caused by the more use of FMA rather than anything else. Aah, I forgot to include that tidbit, because its readily apparent from the full logs - I compiled with *just* -O3. Thanks, OK, perhaps on the aarch64 I need the following option to make the comparison fair: ‘rdma’ Enable Round Double Multiply Accumulate instructions. This is on by default for -march=armv8.1-a. I.e., -mno-rdma (I hope that's correct - I'll will try that when the Sun rises again and I have some power to run the AArch64 machine ...). I must say I didn't expected this - the discussion on the "Intel" side was always that the fact that fused multiply-add instruction didn't express the "real computations" expressed by the program meant that they were evil and therefore had to be hidden behind some special compiler option that made it very clear that those instruction were evil. Again, thanks to point me to the difference (in philosophy, if not math) between to the two continents (i.e., the Americas and Europe's - before Brexit - England :-) Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
