Re: Sourceware forge experiment
On Sun, Oct 20, 2024 at 9:27 PM Mark Wielaard wrote: > > As an experiment Sourceware is now running an forgejo v9 instance at > https://forge.sourceware.org > > Everybody with an @sourceware.org, @cygwin.com or @gcc.gnu.org address > can register an account (please use the same user name as your account > name). > > The setup has disabled most "extras" (no badges, stars, issues, wikis, > packages, timetracking, milestones, etc.). And users can only fork > existing repos (it has mirrors of various sourceware projects). Is the intent to get mirrors of all of them on there at some point? I'm only seeing a few at the moment... > Some things haven't been setup yet (external trackers/bugzilla, incoming > email, ci, etc.) I was able to get the link to an external tracker (the gcc bugzilla) set up in my "gcc-mirror" fork: https://forge.sourceware.org/egallager/gcc-mirror > > The full setup can be found in this git repository: > https://sourceware.org/cgit/forge/ > > For now it is only open for existing maintainers/developers for > experimentating with a pull-request model. So, I tested this out: I forked the gcc-mirror and gcc-wwwdocs-mirror repos, but it looks like the mirror ones aren't accepting PRs at the moment, so I tried forking their "-TEST" variants, but it looks like it won't let me make a fork of the "-TEST" copy since I already have a fork of the "-mirror" one? When I click the "fork" button on one of the "-TEST" repos, it just redirects me back to my existing "-mirror" fork of the corresponding "-mirror" one... > We can add others as long as they understand this is an experiment > and does not mean projects are accepting patches through it. > Contributions should still be sent through the mailinglists. > > There is also a new mailinglist for discussion about the setup and the > best way to create a pull-request workflow. Please subscribe if you > create an account and mention which project/organization you would > like do some experiments for. We can then add you to that organization. > ...is subscribing necessary? I'm trying to limit my subscriptions... > https://sourceware.org/mailman/listinfo/forge
[no subject]
🙏ขออนุญาตแนะนำสำหรับเจ้าของธุรกิจ ที่จดทะเบียนการค้า/พาณิชย์/ หจก. อุตสาหกรรมทั่วไป ทุนหมุนเวียนระยะสั้น อนุมัติง่าย ☑️เริ่มต้น 1.5% - 0.5% ☑️อนุมัติสูงสุด 3,000,000 บาท ☑️ทราบผล ภายใน 30 นาที (หลังส่งเอกสารครบถ้วน) ☑️พร้อมลงพื้นที่ประเมินหน้างานและทำสัญญา ❌ไม่มีนโยบายเรียกชำระก่อนทำสัญญาทุกกรณี❌ ✔️สนใจบริการของเราโทรด่วนหาเรา ติดต่อ : 082-5928-519 คุณเอก LINE : ID esc.credit ต้องขออภัยอีกครั้งหากข้อความนี้เป็นเหตุรบกวนคะ🙏
Automatic URLs in forgejo? (was Re: Sourceware forge experiment)
On Mon, 2024-10-21 at 03:22 +0200, Mark Wielaard wrote: > As an experiment Sourceware is now running an forgejo v9 instance at > https://forge.sourceware.org > > Everybody with an @sourceware.org, @cygwin.com or @gcc.gnu.org > address > can register an account (please use the same user name as your > account > name). > > The setup has disabled most "extras" (no badges, stars, issues, > wikis, > packages, timetracking, milestones, etc.). And users can only fork > existing repos (it has mirrors of various sourceware projects). Some > things haven't been setup yet (external trackers/bugzilla, incoming > email, ci, etc.) > > The full setup can be found in this git repository: > https://sourceware.org/cgit/forge/ > > For now it is only open for existing maintainers/developers for > experimentating with a pull-request model. We can add others as long > as they understand this is an experiment and does not mean projects > are accepting patches through it. Contributions should still be sent > through the mailinglists. > > There is also a new mailinglist for discussion about the setup and > the > best way to create a pull-request workflow. Please subscribe if you > create an account and mention which project/organization you would > like do some experiments for. We can then add you to that > organization. > > https://sourceware.org/mailman/listinfo/forge Thanks for setting this up. How easy would it be to set up automatic URL generation in the web UI from regexes on the text of commit subjects/message? GCC has its own short notation for referring to commits, see e.g. https://forge.sourceware.org/gcc/gcc-mirror/commit/83abdb041426b7490e93c3f77be93148bcd94de3 where I wrote: "I believe this hasn't been necessary since r15-1413-gd3878c85f331c7." It would be nice if the "r15-1413-gd3878c85f331c7" were to get auto- urlified in the web UI to https://forge.sourceware.org/gcc/gcc-mirror/commit/d3878c85f331c7 Similarly, in GCC we use the notation PRnn or PR component/nn to refer to "problem reports" in bugzilla. Looking at e.g. https://forge.sourceware.org/gcc/gcc-mirror/commit/65c5bbe1c92f9c08e99d3a37c136f2ef9804a37f it would be nice if the "PR114423" in the subject line and the "PR preprocessor/114423" in the ChangeLog fragments in the commit log got auto-urlified in the web UI to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114423 Other projects sharing the forgejo instance have other notations, policies, and bug tracker instances, of course. FWIW I seem to recall seeing something like this working in the instance that was recently demoed at Cauldron. Hope this is constructive; thanks again Dave
Re: feature request: a linker option to avoid merging variables from separate object files into shared cache lines
On 24/10/2024 16:35, Jonathan Wakely via Gcc wrote: On Thu, 24 Oct 2024 at 15:00, Mateusz Guzik via Gcc wrote: I understand the stock behavior of pilling variables on may happen to improve cache usage. However, in a multicore setting it is a never-ending source of unintentionally showing up and disappearing false-sharing depending on unrelated variables being added or removed. I'm aware one can manually add padding or explicitly tell the linker to put a specific variable elsewhere, but in large codebases getting to a point where everything is annotated is quite a challenge. To give you one example of a project which did not get there despite literally decades of multicore development: the Linux kernel (or in fact any open-source kernel out there, last I checked). In the meantime a great clutch would contain such problems to a specific .o file. ... For illustrative purposes, I don't care about the name: -align-object-data-section=64 Thoughts? Wouldn't that be a linker option, and so not part of GCC? I would have thought it would be better as part of the compiler. For each compilation unit, you generate one or more data sections depending on the variable initialisations, compiler options and target (.bss, .data, .rodata, .sbss, etc.). If the compiler has "-align-object-data-section=64" in effect, then you could add ".align 64" to the start and the end of each section. As far as I can see, that would give the effect the OP is looking for in a simple manner that can also be different for different translation units in the same program (which would be hard to do with a linker flag). And if this is a flag in gcc, then it will work for any ld-compatible linker (gold, mold, etc.). gcc already generates a ".align" linker command with the minimum alignment required by the variables in the section. This new flag would then do two things - one is set a minimum alignment for the data sections (it can still increase if a variable has bigger alignment, such as via an "_Alignas" specifier or an "aligned" attribute). Secondly, it would add another ".align" command at the end of the section so that if a section with a small alignment specifier is linked after one with a specified large alignment, you'll get padding inserted. mvh., David
Re: Sourceware forge experiment
On Thu, 24 Oct 2024 at 20:44, Eric Gallager wrote: > On Sun, Oct 20, 2024 at 9:27 PM Mark Wielaard wrote: > > > > As an experiment Sourceware is now running an forgejo v9 instance at > > https://forge.sourceware.org > > > > Everybody with an @sourceware.org, @cygwin.com or @gcc.gnu.org address > > can register an account (please use the same user name as your account > > name). > > > > The setup has disabled most "extras" (no badges, stars, issues, wikis, > > packages, timetracking, milestones, etc.). And users can only fork > > existing repos (it has mirrors of various sourceware projects). > > Is the intent to get mirrors of all of them on there at some point? > It's an experiment for people who want to try it out, I don't really see why every project needs to be mirrored there. If nobody from project xyz is interested in experimenting with forgejo, why bother mirroring that project's repo? I'm only seeing a few at the moment... > > > Some things haven't been setup yet (external trackers/bugzilla, incoming > > email, ci, etc.) > > I was able to get the link to an external tracker (the gcc bugzilla) > set up in my "gcc-mirror" fork: > https://forge.sourceware.org/egallager/gcc-mirror > > > > > The full setup can be found in this git repository: > > https://sourceware.org/cgit/forge/ > > > > For now it is only open for existing maintainers/developers for > > experimentating with a pull-request model. > > So, I tested this out: I forked the gcc-mirror and gcc-wwwdocs-mirror > repos, but it looks like the mirror ones aren't accepting PRs at the > moment, so I tried forking their "-TEST" variants, but it looks like > it won't let me make a fork of the "-TEST" copy since I already have a > fork of the "-mirror" one? When I click the "fork" button on one of > the "-TEST" repos, it just redirects me back to my existing "-mirror" > fork of the corresponding "-mirror" one... > Go to the -mirror project's settings and delete the repo. You'll be able to fork the -TEST one after that. > > > We can add others as long as they understand this is an experiment > > and does not mean projects are accepting patches through it. > > Contributions should still be sent through the mailinglists. > > > > There is also a new mailinglist for discussion about the setup and the > > best way to create a pull-request workflow. Please subscribe if you > > create an account and mention which project/organization you would > > like do some experiments for. We can then add you to that organization. > > > > ...is subscribing necessary? I'm trying to limit my subscriptions... > > > https://sourceware.org/mailman/listinfo/forge >
Re: feature request: a linker option to avoid merging variables from separate object files into shared cache lines
On Thu, Oct 24, 2024 at 5:12 PM Jonathan Wakely wrote: > > > > On Thu, 24 Oct 2024 at 16:06, Mateusz Guzik wrote: >> >> On Thu, Oct 24, 2024 at 4:35 PM Jonathan Wakely >> wrote: >> >> For illustrative purposes, I don't care about the name: >> >> -align-object-data-section=64 >> >> >> >> Thoughts? >> > >> > >> > Wouldn't that be a linker option, and so not part of GCC? >> > >> >> Indeed it would be, I assumed this is the right list to prod though. >> >> Who should I e-mail instead? > > > The GNU linker is part of Binutils: > https://sourceware.org/binutils/ > > thanks. I had my brain on llvm, which has everything lumped in. :) -- Mateusz Guzik
Re: Automatic URLs in forgejo? (was Re: Sourceware forge experiment)
On Thu, 24 Oct 2024 at 16:42, Jonathan Wakely wrote: > > > On Thu, 24 Oct 2024 at 16:29, David Malcolm wrote: > >> On Mon, 2024-10-21 at 03:22 +0200, Mark Wielaard wrote: >> > As an experiment Sourceware is now running an forgejo v9 instance at >> > https://forge.sourceware.org >> > >> > Everybody with an @sourceware.org, @cygwin.com or @gcc.gnu.org >> > address >> > can register an account (please use the same user name as your >> > account >> > name). >> > >> > The setup has disabled most "extras" (no badges, stars, issues, >> > wikis, >> > packages, timetracking, milestones, etc.). And users can only fork >> > existing repos (it has mirrors of various sourceware projects). Some >> > things haven't been setup yet (external trackers/bugzilla, incoming >> > email, ci, etc.) >> > >> > The full setup can be found in this git repository: >> > https://sourceware.org/cgit/forge/ >> > >> > For now it is only open for existing maintainers/developers for >> > experimentating with a pull-request model. We can add others as long >> > as they understand this is an experiment and does not mean projects >> > are accepting patches through it. Contributions should still be sent >> > through the mailinglists. >> > >> > There is also a new mailinglist for discussion about the setup and >> > the >> > best way to create a pull-request workflow. Please subscribe if you >> > create an account and mention which project/organization you would >> > like do some experiments for. We can then add you to that >> > organization. >> > >> > https://sourceware.org/mailman/listinfo/forge >> >> Thanks for setting this up. >> >> How easy would it be to set up automatic URL generation in the web UI >> from regexes on the text of commit subjects/message? >> > > Currently not possible, but there's an upstream feature request to support > it: > https://codeberg.org/forgejo/forgejo/issues/3274 > (which is also noted on the wiki page)
Re: Sourceware forge experiment
On Sun, Oct 20, 2024 at 6:26 PM Mark Wielaard wrote: > > As an experiment Sourceware is now running an forgejo v9 instance at > https://forge.sourceware.org > > Everybody with an @sourceware.org, @cygwin.com or @gcc.gnu.org address > can register an account (please use the same user name as your account > name). > > The setup has disabled most "extras" (no badges, stars, issues, wikis, > packages, timetracking, milestones, etc.). And users can only fork > existing repos (it has mirrors of various sourceware projects). Some > things haven't been setup yet (external trackers/bugzilla, incoming > email, ci, etc.) > > The full setup can be found in this git repository: > https://sourceware.org/cgit/forge/ > > For now it is only open for existing maintainers/developers for > experimentating with a pull-request model. We can add others as long > as they understand this is an experiment and does not mean projects > are accepting patches through it. Contributions should still be sent > through the mailinglists. Is the pull request to the gcc:gcc-test repo limited? Do you need extra permissions added to do it? This was not mentioned so I thought I could register with my @gcc.gnu.org account as the email and it would work. Thanks, Andrew Pinski > > There is also a new mailinglist for discussion about the setup and the > best way to create a pull-request workflow. Please subscribe if you > create an account and mention which project/organization you would > like do some experiments for. We can then add you to that organization. > > https://sourceware.org/mailman/listinfo/forge
