Re: How to format code in GCC style?
Hanke Zhang via Gcc writes: > Hi Filip, > > Thanks for your reply. But I'm not so familiar with VIM actually. Thus > when I try the options listed there, nothing happened. (VSCODE is the > IDE I'm using for development.) > > And I notice that there is a `vimrc` in the `contrib` directory, I > tried it too, but sadly, it didn't work for me. > > Maybe I configured vim in some wrong way. Hello, there's also a clang-format config file in contrib/clang-format. We're using this for gcc-rs. Marc
Re: 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++ \ --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 ``` Took a little more than 4.5 hours on a rx2800 i2 w/1 x Itanium 2 9320 when performed below `/dev/shm`: ``` time make -j9 [...] real275m54.878s user1907m4.200s sys 23m48.405s ``` Running the gcc and g++ testsuites in parallel now. Should take another 5 hours or so... Cheers, Frank On 30.04.24 12:33, Jakub Jelinek via Gcc wrote: The first release candidate for GCC 14.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/ ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/ and shortly its mirrors. It has been generated from git commit r14-10154-g7a00c459cbb913a. 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 like to release 14.1 on Tuesday, May 7th.
Re: Updated Sourceware infrastructure plans
On 4/22/24 9:24 PM, Tom Tromey wrote: Jason> Someone mentioned earlier that gerrit was previously tried Jason> unsuccessfully. We tried it and gdb and then abandoned it. We tried to integrate it into the traditional gdb development style, having it send email to gdb-patches. I found these somewhat hard to read and in the end we agreed not to use it. I've come around again to thinking we should probably abandon email instead. For me the main benefit is that gerrit has patch tracking, unlike our current system, where losing patches is fairly routine. Jason> I think this is a common pattern in GCC at least: someone has an Jason> idea for a workflow improvement, and gets it working, but it Jason> isn't widely adopted. It essentially has to be mandated, IMO. For GCC this seems somewhat harder since the community is larger, so there's more people to convince. I tend to think it's the principal reviewers that will drive this. If several of the key folks indicated they were going to use system XYZ, whatever it is, that would drive everyone to that system. We're currently using patchwork to track patches tagged with RISC-V. We don't do much review with patchwork. In that model patchwork ultimately just adds overhead as I'm constantly trying to figure out what patches have been integrated vs what are still outstanding. Patchwork definitely isn't the answer IMHO. Nor is gitlab MRs which we use heavily internally. But boy I want to get away from email and to a pull request kind of flow. jeff
Re: Updated Sourceware infrastructure plans
On Wed, 1 May 2024 at 20:19, Jeff Law via Gcc wrote: > > > > On 4/22/24 9:24 PM, Tom Tromey wrote: > > Jason> Someone mentioned earlier that gerrit was previously tried > > Jason> unsuccessfully. > > > > We tried it and gdb and then abandoned it. We tried to integrate it > > into the traditional gdb development style, having it send email to > > gdb-patches. I found these somewhat hard to read and in the end we > > agreed not to use it. > > > > I've come around again to thinking we should probably abandon email > > instead. For me the main benefit is that gerrit has patch tracking, > > unlike our current system, where losing patches is fairly routine. > > > > Jason> I think this is a common pattern in GCC at least: someone has an > > Jason> idea for a workflow improvement, and gets it working, but it > > Jason> isn't widely adopted. > > > > It essentially has to be mandated, IMO. > > > > For GCC this seems somewhat harder since the community is larger, so > > there's more people to convince. > I tend to think it's the principal reviewers that will drive this. If > several of the key folks indicated they were going to use system XYZ, > whatever it is, that would drive everyone to that system. > > We're currently using patchwork to track patches tagged with RISC-V. We > don't do much review with patchwork. In that model patchwork ultimately > just adds overhead as I'm constantly trying to figure out what patches > have been integrated vs what are still outstanding. If patches sent by email exactly match what's committed, then the update_gcc_pw.sh script that I run will correctly update patchwork to say they're committed. I tend to only bother running that once a week, because it misses so many and so is of limited use. If we are now supposed to send generated files in the patches, and we discourage people from committing something close-but-not-identical to what they sent by email, then the script will do a better job of updating patchwork, and then we should look at running it automatically (not just when I think to run it manually). I think there's still an issue where a patch has been superseded by a v2 which has been committed. I don't think patchwork does a good job of noticing that the v1 patch is no longer relevant, so somebody still has to manually update those ones. So overall, I agree that patchwork isn't the answer. It requires too much manual housekeeping, and that's a huge task with the volume of patches that GCC has. > > Patchwork definitely isn't the answer IMHO. Nor is gitlab MRs which we > use heavily internally. But boy I want to get away from email and to a > pull request kind of flow. > > jeff
Re: Updated Sourceware infrastructure plans
On 5/1/24 12:15, Jeff Law wrote: On 4/22/24 9:24 PM, Tom Tromey wrote: Jason> Someone mentioned earlier that gerrit was previously tried Jason> unsuccessfully. We tried it and gdb and then abandoned it. We tried to integrate it into the traditional gdb development style, having it send email to gdb-patches. I found these somewhat hard to read and in the end we agreed not to use it. I've come around again to thinking we should probably abandon email instead. For me the main benefit is that gerrit has patch tracking, unlike our current system, where losing patches is fairly routine. Jason> I think this is a common pattern in GCC at least: someone has an Jason> idea for a workflow improvement, and gets it working, but it Jason> isn't widely adopted. It essentially has to be mandated, IMO. For GCC this seems somewhat harder since the community is larger, so there's more people to convince. I tend to think it's the principal reviewers that will drive this. If several of the key folks indicated they were going to use system XYZ, whatever it is, that would drive everyone to that system. We're currently using patchwork to track patches tagged with RISC-V. We don't do much review with patchwork. In that model patchwork ultimately just adds overhead as I'm constantly trying to figure out what patches have been integrated vs what are still outstanding. Patchwork definitely isn't the answer IMHO. Nor is gitlab MRs which we use heavily internally. But boy I want to get away from email and to a pull request kind of flow. Do you (or others) have any thoughts about GitLab FOSS? Jason
Re: Updated Sourceware infrastructure plans
Hi Jonathan, On Wed, May 01, 2024 at 08:38:26PM +0100, Jonathan Wakely wrote: > On Wed, 1 May 2024 at 20:19, Jeff Law via Gcc wrote: > > We're currently using patchwork to track patches tagged with RISC-V. We > > don't do much review with patchwork. In that model patchwork ultimately > > just adds overhead as I'm constantly trying to figure out what patches > > have been integrated vs what are still outstanding. > > If patches sent by email exactly match what's committed, then the > update_gcc_pw.sh script that I run will correctly update patchwork to > say they're committed. I tend to only bother running that once a week, > because it misses so many and so is of limited use. If we are now > supposed to send generated files in the patches, and we discourage > people from committing something close-but-not-identical to what they > sent by email, then the script will do a better job of updating > patchwork, and then we should look at running it automatically (not > just when I think to run it manually). See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997 We really should automate this. There are several people running scripts by hand. The easiest would be to simply run it from a git hook. patchwork comes with a simple script that just calculates the hash and pings patchwork, which can then mark the patch associated with that hash as committed. If people really believe calculating a hash is too much work from a git hook then we can also simply run it from builder.sourceware.org. We already run a builder for each commit anyway. It would just be one extra build step checking the commit against patchwork. Cheers, Mark
Re: Updated Sourceware infrastructure plans
Mark> See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997 Mark> We really should automate this. There are several people running Mark> scripts by hand. The easiest would be to simply run it from a git Mark> hook. patchwork comes with a simple script that just calculates the Mark> hash and pings patchwork, which can then mark the patch associated Mark> with that hash as committed. If people really believe calculating a Mark> hash is too much work from a git hook then we can also simply run it Mark> from builder.sourceware.org. We already run a builder for each commit Mark> anyway. It would just be one extra build step checking the commit Mark> against patchwork. There's just no possibility this approach will work for gdb. It can't reliably recognize when a series is re-sent, or when patches land that are slightly different from what was submitted. Both of these are commonplace events in gdb. Tom
Re: Updated Sourceware infrastructure plans
On 2024-05-01 16:53, Tom Tromey via Overseers wrote: > Mark> See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997 > Mark> We really should automate this. There are several people running > Mark> scripts by hand. The easiest would be to simply run it from a git > Mark> hook. patchwork comes with a simple script that just calculates the > Mark> hash and pings patchwork, which can then mark the patch associated > Mark> with that hash as committed. If people really believe calculating a > Mark> hash is too much work from a git hook then we can also simply run it > Mark> from builder.sourceware.org. We already run a builder for each commit > Mark> anyway. It would just be one extra build step checking the commit > Mark> against patchwork. > > There's just no possibility this approach will work for gdb. It can't > reliably recognize when a series is re-sent, or when patches land that > are slightly different from what was submitted. Both of these are > commonplace events in gdb. > > Tom IMO, asking to always post the committed version as is (effectively preventing doing "pushed with those nits fixed", or solving trivial merge conflicts just before pushing) just to make patchwork happy would be annoying and an additional burden, and noise on the mailing list. The Change-Id trailer works very well for Gerrit: once you have the hook installed you basically never have to think about it again, and Gerrit is able to track patch versions perfectly accurately. A while ago, I asked patchwork developers if they would be open to support something like that to track patches, and they said they wouldn't be against it (provided it's not mandatory) [1]. But somebody would have to implement it. Simon [1] https://github.com/getpatchwork/patchwork/issues/327
Re: Updated Sourceware infrastructure plans
Hi Jason, On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote: > On 5/1/24 12:15, Jeff Law wrote: > >We're currently using patchwork to track patches tagged with > >RISC-V. We don't do much review with patchwork. In that model > >patchwork ultimately just adds overhead as I'm constantly trying > >to figure out what patches have been integrated vs what are still > >outstanding. > > > >Patchwork definitely isn't the answer IMHO. Nor is gitlab MRs > >which we use heavily internally. But boy I want to get away from > >email and to a pull request kind of flow. > > Do you (or others) have any thoughts about GitLab FOSS? The gitlab "community edition" still feels not very much "community". We could run our own instance, but it will still be "open core" with features missing to try to draw you towards the proprietary hosted saas version. Also it seems to have way too much overhead. The focus is clearly corporate developers where managers want assurances the mandatory "pipelines" are executed and "workflows" followed exactly. For now I am cleaning up Sergio's gerrit setup and upgrading it to the latest version, so people can at least try it out. Although I must admit that I seem to be the only Sourcewware PLC member that believes this is very useful use of our resources. Even the biggest proponents of gerrit seem to believe no project will actually adopt it. And on irc there were some people really critical of the effort. It seems you either love or really hate gerrit... But the part that interests me most is the self-registration part that Sergio setup. I believe we will need that for whatever system we end up with to make it as easy to contribute as it is with email. https://blog.sergiodj.net/posts/installing-gerrit-and-keycloak/ My personal favorite, if we really want a full "forge" would be sourcehut. We already have mirrors of all projects at https://sr.ht/~sourceware/ and there is a kind of sample "workflow" (turning a "pull request" into an email thread) at https://gnu.wildebeest.org/~mark/fsf-sourceware/presentation.html#slide18 At the moment though the only thing people seem to agree on is that any system will be based on git. So the plan for now is to first setup a larger git(olite) system so that every contributor (also those who don't currently have commit access) can easily "post" their git repo. This can then hopefully integrate with the systems we already have setup (triggering builder CI, flag/match with patchwork/emails, etc.) or any future "pull request" like system. Cheers, Mark
Re: Updated Sourceware infrastructure plans
On 5/1/24 2:04 PM, Jason Merrill wrote: On 5/1/24 12:15, Jeff Law wrote: On 4/22/24 9:24 PM, Tom Tromey wrote: Jason> Someone mentioned earlier that gerrit was previously tried Jason> unsuccessfully. We tried it and gdb and then abandoned it. We tried to integrate it into the traditional gdb development style, having it send email to gdb-patches. I found these somewhat hard to read and in the end we agreed not to use it. I've come around again to thinking we should probably abandon email instead. For me the main benefit is that gerrit has patch tracking, unlike our current system, where losing patches is fairly routine. Jason> I think this is a common pattern in GCC at least: someone has an Jason> idea for a workflow improvement, and gets it working, but it Jason> isn't widely adopted. It essentially has to be mandated, IMO. For GCC this seems somewhat harder since the community is larger, so there's more people to convince. I tend to think it's the principal reviewers that will drive this. If several of the key folks indicated they were going to use system XYZ, whatever it is, that would drive everyone to that system. We're currently using patchwork to track patches tagged with RISC-V. We don't do much review with patchwork. In that model patchwork ultimately just adds overhead as I'm constantly trying to figure out what patches have been integrated vs what are still outstanding. Patchwork definitely isn't the answer IMHO. Nor is gitlab MRs which we use heavily internally. But boy I want to get away from email and to a pull request kind of flow. Do you (or others) have any thoughts about GitLab FOSS? I would assume its basically the same as gitlab, except with any proprietary removed and that new features land in the enterprise version first and presumably migrate to the FOSS version over time. What works well? If you've wired up some CI bits, it's is extremely useful to test an under development patch. Develop, push a branch, raise an MR. At that point the CI system kicks in. Subsequent pushes to the branch trigger fresh CI runs. This aspect I really like and if you were to see internal flows, you'd see dev branches churning as a patch gets iterated on. It also has features like "when this passes CI, automatically commit it", which we often use on the final patch iteration if there was a nit of some kind. What doesn't? Finding things in gitlab is *awful*. Now we're just talking about one repo, so it may be more manageable in that regard. And we're not talking about using it for bug tracking. As long as we kept on top of the MR queue, maybe it would be feasible. So maybe I should soften my stance on gitlab. If we're not using it for bug tracking and hosting many projects, then maybe its viable. I think the driving force will be whether or not folks like you, Richi and others that do a ton of patch review would be more efficient in a gui or not. I don't think I am, but maybe that would change if I did it every day for decades like I did with email :-) jeff
Re: Updated Sourceware infrastructure plans
On Wednesday, May 01 2024, Mark Wielaard wrote: [...] > But the part that interests me most is the self-registration part that > Sergio setup. I believe we will need that for whatever system we end > up with to make it as easy to contribute as it is with email. > https://blog.sergiodj.net/posts/installing-gerrit-and-keycloak/ [...] Hey Mark, If I were to set this up today, I would look at Authentik (which is what I'm using for my personal services). It is a bit simpler than Keycloak. I would also certainly go for a container deployment of the service instead, because (as you can see in the blog post) it's not trivial to set things up in a correct manner. Let me know if you need help with this! Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
gcc-11-20240501 is now available
Snapshot gcc-11-20240501 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240501/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 754b14b98946894240ddc62e96d497194353bfe0 You'll find: gcc-11-20240501.tar.xz Complete GCC SHA256=1eb68ccebbb0492bf8fd12ef0ff442812dbca45f907132f411a522c5506118f2 SHA1=6e619e25759a1f4a2d57dca75257dd27f473c7dd Diffs from 11-20240425 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Updated Sourceware infrastructure plans
> Do you (or others) have any thoughts about GitLab FOSS?
Dunno about the FOSS edition specifically, but I've used many review
tools in anger in the last 5 years: github, gitlab, gerrit, phabricator,
and a couple that ran in bugzilla ("MozReview", not sure if it had some
other name; and a second one that I think was nameless).
For the most part they are pretty similar, IMO, and just the gloss
differs. I didn't like some aspects of phabricator but I no longer full
recall what. Maybe its support for patch series was weaker.
For github/gitlab, I think it's probably nicer if you're also using
their bug tracker. Those also seem totally fine by and large. Nicer
than bugzilla in some ways (nicer / more responsive UI), worse in others
(searching is not as good).
Tom
Re: Updated Sourceware infrastructure plans
On Wed, May 1, 2024 at 11:41 PM Jeff Law via Gcc wrote: > > > > On 5/1/24 2:04 PM, Jason Merrill wrote: > > On 5/1/24 12:15, Jeff Law wrote: > >> > >> > >> On 4/22/24 9:24 PM, Tom Tromey wrote: > >>> Jason> Someone mentioned earlier that gerrit was previously tried > >>> Jason> unsuccessfully. > >>> > >>> We tried it and gdb and then abandoned it. We tried to integrate it > >>> into the traditional gdb development style, having it send email to > >>> gdb-patches. I found these somewhat hard to read and in the end we > >>> agreed not to use it. > >>> > >>> I've come around again to thinking we should probably abandon email > >>> instead. For me the main benefit is that gerrit has patch tracking, > >>> unlike our current system, where losing patches is fairly routine. > >>> > >>> Jason> I think this is a common pattern in GCC at least: someone has an > >>> Jason> idea for a workflow improvement, and gets it working, but it > >>> Jason> isn't widely adopted. > >>> > >>> It essentially has to be mandated, IMO. > >>> > >>> For GCC this seems somewhat harder since the community is larger, so > >>> there's more people to convince. > >> I tend to think it's the principal reviewers that will drive this. If > >> several of the key folks indicated they were going to use system XYZ, > >> whatever it is, that would drive everyone to that system. > >> > >> We're currently using patchwork to track patches tagged with RISC-V. > >> We don't do much review with patchwork. In that model patchwork > >> ultimately just adds overhead as I'm constantly trying to figure out > >> what patches have been integrated vs what are still outstanding. > >> > >> Patchwork definitely isn't the answer IMHO. Nor is gitlab MRs which > >> we use heavily internally. But boy I want to get away from email and > >> to a pull request kind of flow. > > > > Do you (or others) have any thoughts about GitLab FOSS? > I would assume its basically the same as gitlab, except with any > proprietary removed and that new features land in the enterprise version > first and presumably migrate to the FOSS version over time. > > > What works well? If you've wired up some CI bits, it's is extremely > useful to test an under development patch. Develop, push a branch, > raise an MR. At that point the CI system kicks in. Subsequent pushes > to the branch trigger fresh CI runs. This aspect I really like and if > you were to see internal flows, you'd see dev branches churning as a > patch gets iterated on. It also has features like "when this passes CI, > automatically commit it", which we often use on the final patch > iteration if there was a nit of some kind. > > > > > What doesn't? Finding things in gitlab is *awful*. Now we're just > talking about one repo, so it may be more manageable in that regard. > And we're not talking about using it for bug tracking. As long as we > kept on top of the MR queue, maybe it would be feasible. > > So maybe I should soften my stance on gitlab. If we're not using it for > bug tracking and hosting many projects, then maybe its viable. > > I think the driving force will be whether or not folks like you, Richi > and others that do a ton of patch review would be more efficient in a > gui or not. I don't think I am, but maybe that would change if I did it > every day for decades like I did with email :-) We'd only know for sure if we try. But then I'm almost 100% sure that having to click in a GUI is slower than 'nrOK^X' in the text-mode mail UA I am using for "quick" patch review. It might be comparable to the review parts I do in the gmail UI or when I have to download attachments and cut&paste parts into the reply. It might be also more convenient for "queued" for review patches which just end up in New state in either inbox. But then would using gitlab or any similar service enforce the use of pull requests / forks for each change done or can I just continue to post patches and push them from the command-line for changes I can approve myself? Btw, for any forge like tool I'd even consider there'd be the requirement that _all_ functionality is also accessible via a documented (stable) API, aka there's command-line tooling available or at least possible to write. Richard. > jeff > >
