Re: feature request: a linker option to avoid merging variables from separate object files into shared cache lines
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/
Re: Automatic URLs in forgejo? (was Re: Sourceware forge experiment)
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
feature request: a linker option to avoid merging variables from separate object files into shared cache lines
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. To illustrate, suppose there are 3 .o files with variables spanning 2 cache lines. The first .o file has something frequently read and it lands in the first cache line. At the same time the last .o file has a frequently modified var and it currently lands in the second cache line. Now some vars got removed from the "middle" .o file and as a result the frequently modified var is pulled up to the first cache line, false-sharing with a frequently read var from something unrelated. This results in a slowdown stemming from a change which should have no impact. I once more note ideally this all would be annotated in project-specific ways, but so far even Linux did not get there despite playing whack-a-mole. An option to keep variables from different .o files in separate lines would be a great damage-controlling measure. I'll note even on CPUs with 64 byte cache lines one may want to pick a higher value (e.g., due to the adjacent cache line prefetcher on Intel CPUs). Thus the best option would probably accept an argument specifying how much alignment one expects. For illustrative purposes, I don't care about the name: -align-object-data-section=64 Thoughts? -- Mateusz Guzik
Re: Sourceware forge experiment
On Thu, Oct 24, 2024 at 1:25 PM Andrew Pinski wrote: > > 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. Never mind, it is just brokeness of the way of the test repos work. The problem will not show up in the final thing so I am less worried. > > 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
Re: feature request: a linker option to avoid merging variables from separate object files into shared cache lines
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. > > To illustrate, suppose there are 3 .o files with variables spanning 2 > cache lines. The first .o file has something frequently read and it > lands in the first cache line. At the same time the last .o file has a > frequently modified var and it currently lands in the second cache > line. > > Now some vars got removed from the "middle" .o file and as a result > the frequently modified var is pulled up to the first cache line, > false-sharing with a frequently read var from something unrelated. > > This results in a slowdown stemming from a change which should have no > impact. > > I once more note ideally this all would be annotated in > project-specific ways, but so far even Linux did not get there despite > playing whack-a-mole. > > An option to keep variables from different .o files in separate lines > would be a great damage-controlling measure. > > I'll note even on CPUs with 64 byte cache lines one may want to pick a > higher value (e.g., due to the adjacent cache line prefetcher on Intel > CPUs). Thus the best option would probably accept an argument > specifying how much alignment one expects. > > 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?
Re: feature request: a linker option to avoid merging variables from separate object files into shared cache lines
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? -- Mateusz Guzik
Introduction and Interest in GSOC 2025
Dear GCC Community, My name is Nainika Reddy Vempalli and I'm currently a second year Computer Science Student with a background in C/C++. I am interested in participating in *Google Summer Of Code 2025* with *GNU Compiler Organisation* focusing mainly on improving the GCC webpages. As someone new to open source contributions and web development, I'm eager to start working on the web pages by improving both the UI Design and the user interface. My goal is to enhance the experience for new contributors, users and developers. I would be grateful for any advice that you can offer on how to start contributing to the gcc webpages and I would love any advice regarding: - How to approach website contributions - Learning Resources(Particularly in Perl as it is involved in the website's development) - Smaller tasks or bugs that are beginner friendly Thank you in advance for your support and I look forward to hearing from you.
Re: Introduction and Interest in GSOC 2025
Dear Martin and GCC Community, Thank you for clarifying the GSoC requirements for GCC. While I initially hoped to work on the GCC webpages, I am still very eager to participate in *GSoC 2025 with GCC* and contribute to the project in a meaningful way. I would be happy to pivot my focus to areas that align more closely with *compiler development, testing infrastructure*, or other aspects within GCC’s core scope. As I am relatively new to compiler development, I would greatly appreciate any guidance on beginner-friendly areas or potential projects in these areas that may be suitable for GSoC. I am committed to expanding my skills in *C/C++* and learning any additional technologies needed to contribute effectively. Thank you again for your insights, and I look forward to any advice you may have on potential contributions. Best regards, Nainika Reddy Vempalli On Fri, 25 Oct 2024 at 17:07, Martin Jambor wrote: > Hello Monika, > > On Fri, Oct 25 2024, Nainika Reddy Vempalli via Gcc wrote: > > Dear GCC Community, > > > > My name is Nainika Reddy Vempalli and I'm currently a second year > > Computer Science Student with a background in C/C++. I am interested in > > participating in *Google Summer Of Code 2025* with *GNU Compiler > > Organisation* focusing mainly on improving the GCC webpages. > > unfortunately we have to disappoint you. There is hardly anything on > the GCC web page that can be considered not to be documentation and > Google Summer of Code rules[1] (specifically rule 1.26) do not allow > purely documentation projects. > > Also, in our GSoC projects we generally focus on the compiler itself > together with the associated libraries and tools. > > I hope you'll have better luck elsewhere, perhaps with some project that > itself is closer to web development. > > Martin > > > [1] https://summerofcode.withgoogle.com/rules > > > > > As someone new to open source contributions and web development, > > I'm eager to start working on the web pages by improving both the UI > Design > > and the user interface. My goal is to enhance the experience for new > > contributors, users and developers. > > > >I would be grateful for any advice that you can offer on how to > > start contributing to the gcc webpages and I would love any advice > > regarding: > > > >- How to approach website contributions > >- Learning Resources(Particularly in Perl as it is involved in the > > website's development) > >- Smaller tasks or bugs that are beginner friendly > > > > > > Thank you in advance for your support and I look forward to hearing from > > you. >
C
Sent from my iPhone gf fy
Re: Automatic URLs in forgejo? (was Re: Sourceware forge experiment)
On 24/10/2024 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? > > 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 > See the wiki page I added today for setting up bugzilla (gcc.gnu.org/wiki/ForgeExperiment). It only works for the / style due to limitations in the way forgejo uses the regex groups. > 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: Introduction and Interest in GSOC 2025
Hello Monika, On Fri, Oct 25 2024, Nainika Reddy Vempalli via Gcc wrote: > Dear GCC Community, > > My name is Nainika Reddy Vempalli and I'm currently a second year > Computer Science Student with a background in C/C++. I am interested in > participating in *Google Summer Of Code 2025* with *GNU Compiler > Organisation* focusing mainly on improving the GCC webpages. unfortunately we have to disappoint you. There is hardly anything on the GCC web page that can be considered not to be documentation and Google Summer of Code rules[1] (specifically rule 1.26) do not allow purely documentation projects. Also, in our GSoC projects we generally focus on the compiler itself together with the associated libraries and tools. I hope you'll have better luck elsewhere, perhaps with some project that itself is closer to web development. Martin [1] https://summerofcode.withgoogle.com/rules > > As someone new to open source contributions and web development, > I'm eager to start working on the web pages by improving both the UI Design > and the user interface. My goal is to enhance the experience for new > contributors, users and developers. > >I would be grateful for any advice that you can offer on how to > start contributing to the gcc webpages and I would love any advice > regarding: > >- How to approach website contributions >- Learning Resources(Particularly in Perl as it is involved in the > website's development) >- Smaller tasks or bugs that are beginner friendly > > > Thank you in advance for your support and I look forward to hearing from > you.
Re: feature request: a linker option to avoid merging variables from separate object files into shared cache lines
On Thu, Oct 24, 2024 at 9:48 PM David Brown via Gcc wrote: > > 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. It also would need compiler support for the LTO case where what is a linker "object unit" is different from the source "translation unit". But there the question is what's the desired behavior? Currently you'd need to use -flto-partition=1to1 to get the mapping of translation unit to object unit the same as when not using LTO. Richard. > 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 >
gcc-13-20241025 is now available
Snapshot gcc-13-20241025 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20241025/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision 18af118e17bd0787638967725047f7241e43b2b2 You'll find: gcc-13-20241025.tar.xz Complete GCC SHA256=4037d42450869b785d5134aa674180b227bb9cc752b265c2ce1d8158ac651b15 SHA1=d69e072ac5d39b2746f9f8492d85b99caeb4af76 Diffs from 13-20241018 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 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.
