gcc-12-20240301 is now available
Snapshot gcc-12-20240301 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240301/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 9d033155254ac6df5f47ab32896dbf336f991589 You'll find: gcc-12-20240301.tar.xz Complete GCC SHA256=02034c6cf420515b0924bc24f46434abd2fd12d8959954cc69a0ba7a2b335d96 SHA1=53b2d1d0255aae36bb5a8ddc0ea9b41b06937349 Diffs from 12-20240223 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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: Help needed with maintainer-mode
On Fri, 1 Mar 2024 at 14:08, Mark Wielaard wrote: > > Hi Christophe, > > On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote: > > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote: > > > That python script works across gcc/binutils/gdb: > > > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py > > > > > > It is installed into a container file that has the exact autoconf and > > > automake version needed to regenerate the autotool files: > > > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools > > > > > > And it was indeed done this way because that way the files are > > > regenerated in a reproducible way. Which wasn't the case when using > > > --enable-maintainer-mode (and autoreconfig also doesn't work). > > > > I see. So it is possibly incomplete, in the sense that it may lack > > some of the steps that maintainer-mode would perform? > > For instance, gas for aarch64 has some *opcodes*.c files that need > > regenerating before committing. The regeneration step is enabled in > > maintainer-mode, so I guess the autoregen bots on Sourceware would > > miss a problem with these files? > > Yes, it is certainly incomplete. But it is done this way because it is > my understanding that even the gcc release maintainers do the > automake/autoconf invocations by hand instead of running with configure > --enable-maintainer-mode. After a discussion on IRC, I read https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration which basically says "run autoreconf in every dir where there is a configure script" but this is not exactly what autoregen.py is doing. IIRC it is based on a script from Martin Liska, do you know/remember why it follows a different process? Thanks, Christophe > > Note that another part that isn't caught at the moment are the > regeneration of the opt.urls files. There is a patch for that pending: > https://inbox.sourceware.org/buildbot/20231215005908.gc12...@gnu.wildebeest.org/ > > But that is waiting for the actual opt.urls to be regenerated correctly > first: > https://inbox.sourceware.org/gcc-patches/20240224174258.gd1...@gnu.wildebeest.org/ > Ping David? > > It would be nice to have all these "regeneration targets" in one script > that could be used by both the pre-commit and post-commit checkers. > > Cheers, > > Mark
Re: GSoC 2024 Expression of interes
Hello, On Wed, Feb 28 2024, Aditya Ballaki via Gcc wrote: > Hi Team, > > I'm an incoming graduate student in Computer Engineering at Cornell > University, and I'm keen on participating in GSOC by contributing to > open-source projects before starting my graduate program. Wonderful, welcome! > Specifically, I'm interested in working on the Rust GCC compiler. Please note that Rust-GCC projects are a bit special in the sense that they are often discussed primarily on Zulip of the gcc-rust team: https://gcc-rust.zulipchat.com/ So you may want to reach out to gcc-rust developers there there as well. > While I haven't made direct open-source contributions before, I'm > quite familiar with Rust. I've also gained experience with C/C++ > through various projects involving low-level hardware programming and > video game development. Moreover, I've worked with several other tech > stacks and production-level code during my internships and research > endeavours. > > Please let me know if it's appropriate for me to reach out to any of > the listed mentors (Pierre-Emmanuel Patry, Philip Herron, Arthur > Cohen) to discuss the project further. It is, but I'd primarily suggest the zulip link given above. Good luck! Martin
Re: GSOC
Hello, On Tue, Feb 27 2024, Pratush Rai via Gcc wrote: > I want to work on the Rust Front End project as per the idea list. I am a > rust compiler contributor and want to start contributing to gcc. > I need some guidance on how to start. Please note that Rust-GCC projects are a bit special in the sense that they are often discussed primarily on Zulip of the gcc-rust team: https://gcc-rust.zulipchat.com/ So you may want to reach out to gcc-rust developers there there as well. Apart from this, I can only point you to https://gcc.gnu.org/wiki/SummerOfCode and specifically to https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply which explains some of the steps you can take to familiarize yourself with our code base. Good luck! Martin Jambor
Re: Participation In GSoC 2024
Hello, On Fri, Feb 23 2024, Mohd Kashif via Gcc wrote: > Hey Sir/Madam, > I want to participate in gsoc 2024 but I don't have any experience in it. > Please be my mentor in this and help me to deliver the best project from my > side . We are delighted you found contributing to GCC interesting. Please have a look at https://gcc.gnu.org/wiki/SummerOfCode and specifically at https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply which explains some of the steps you can take to familiarize yourself with our code base and other initial steps to take. Good luck, Martin Jambor
Re: Contributor to the GSoC of 2024
Hello, On Thu, Feb 22 2024, Suraj Kadapa via Gcc wrote: > Hello, > > I am an undergraduate student with an extensive experience in computers > from an early age, but most of my work has been limited to arduinos, and > raspberry pi's. I have been intrigued with compilers, architecture and low > level programming in the past few years. I have experience with ARM > assembly and a little bit of x86 too. I have worked towards building > bootloaders and teaching it to my fellow peers too. I've constructed a > process virtual machine modeled after the LC-3 architecture and am > presently focused on developing a basic emulator for RISC-V. Both of the > previously mentioned projects are being done in C, and I have extensive > experience in C. I really want to know how the GNU Compiler collection > works under the hood and this is a really good opportunity for me to > explore and learn. We are delighted you found contributing to GCC interesting. The above is impressive but you may want to also look into some rudimentary theoretical background in the area of compilers and compiler optimizations, at least you need to understand the term "intermediate representation" (IR) - sometimes also called "intermediate language" (IL). Most of GCC is written in C++, but that should not be an obstacle for an experienced C programmer. > > Please reach out to me on what needs to be done to be accepted as a > contributor to the GSoC program under the GNU organization, The first steps are described in the "Before you apply" section of the GSoC wiki page: https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply > I would love to > work on any of the projects mentioned in the wiki(would prefer some easy > ones though, since I am not that deep yet). Well, you will have to be the one to pick one. Given your interests, I'd recommend looking at "Offloading to a separate process on the same host" and (recently added) "Implement structured dumping of GENERIC." But don't let me discourage you looking at Fortran or any of the others if you think that could be your thing. > > My github will be linked below, and I hope to hear from you soon! > https://github.com/surajkadapa > > This is my first time writing for the GSoC program, so I am not really sure > if this is how you reach out to organizations in this capacity. Please > excuse any potential oversights as I navigate this process. > So far you have done the right thing. Build GCC from source, try to make some sense out of the source on the high level, pick a projet and start thinking what parts would need changing and roughly how to implement. If you have specific questions with the above, feel free to ask on this mailing list or on IRC. Good luck! Martin
Re: Help needed with maintainer-mode
On Fri, 1 Mar 2024 at 14:08, Mark Wielaard wrote: > > Hi Christophe, > > On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote: > > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote: > > > That python script works across gcc/binutils/gdb: > > > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py > > > > > > It is installed into a container file that has the exact autoconf and > > > automake version needed to regenerate the autotool files: > > > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools > > > > > > And it was indeed done this way because that way the files are > > > regenerated in a reproducible way. Which wasn't the case when using > > > --enable-maintainer-mode (and autoreconfig also doesn't work). > > > > I see. So it is possibly incomplete, in the sense that it may lack > > some of the steps that maintainer-mode would perform? > > For instance, gas for aarch64 has some *opcodes*.c files that need > > regenerating before committing. The regeneration step is enabled in > > maintainer-mode, so I guess the autoregen bots on Sourceware would > > miss a problem with these files? > > Yes, it is certainly incomplete. But it is done this way because it is > my understanding that even the gcc release maintainers do the > automake/autoconf invocations by hand instead of running with configure > --enable-maintainer-mode. Indeed, I've just discovered that earlier today :-) > > Note that another part that isn't caught at the moment are the > regeneration of the opt.urls files. There is a patch for that pending: Indeed. I hadn't thought of it either. And just noticed it requires the D frontend, which we don't build in CI. > https://inbox.sourceware.org/buildbot/20231215005908.gc12...@gnu.wildebeest.org/ > > But that is waiting for the actual opt.urls to be regenerated correctly > first: > https://inbox.sourceware.org/gcc-patches/20240224174258.gd1...@gnu.wildebeest.org/ > Ping David? > > It would be nice to have all these "regeneration targets" in one script > that could be used by both the pre-commit and post-commit checkers. > Agreed. > Cheers, > > Mark
Re: Help needed with maintainer-mode
Hi Christophe, On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote: > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote: > > That python script works across gcc/binutils/gdb: > > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py > > > > It is installed into a container file that has the exact autoconf and > > automake version needed to regenerate the autotool files: > > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools > > > > And it was indeed done this way because that way the files are > > regenerated in a reproducible way. Which wasn't the case when using > > --enable-maintainer-mode (and autoreconfig also doesn't work). > > I see. So it is possibly incomplete, in the sense that it may lack > some of the steps that maintainer-mode would perform? > For instance, gas for aarch64 has some *opcodes*.c files that need > regenerating before committing. The regeneration step is enabled in > maintainer-mode, so I guess the autoregen bots on Sourceware would > miss a problem with these files? Yes, it is certainly incomplete. But it is done this way because it is my understanding that even the gcc release maintainers do the automake/autoconf invocations by hand instead of running with configure --enable-maintainer-mode. Note that another part that isn't caught at the moment are the regeneration of the opt.urls files. There is a patch for that pending: https://inbox.sourceware.org/buildbot/20231215005908.gc12...@gnu.wildebeest.org/ But that is waiting for the actual opt.urls to be regenerated correctly first: https://inbox.sourceware.org/gcc-patches/20240224174258.gd1...@gnu.wildebeest.org/ Ping David? It would be nice to have all these "regeneration targets" in one script that could be used by both the pre-commit and post-commit checkers. Cheers, Mark
Re: getting start with GSoC
Hello, On Fri, Feb 16 2024, Nada Elsayed via Gcc wrote: > Hello All, > I am Nada Elsayed, A fresh graduate from computer engineering at Cairo > University. welcome, we are delighted you found contributing to GCC interesting. > I have good knowledge in C/C++, and a basic knowledge in compilers. als I > am interested in contributing to the GCC this year; I am interested in > "*Extend > the static analysis pass" *projects Any particular one? > or "*Improve nothrow detection in GCC" project*.* > > Till now I have built the code and I am trying to understand it more. Good, this is the all-important first step. > So what should I do now? "Trying to understand it more" is exactly the correct thing to. You also need to locate which of the bits within GCC are relevant to the project(s) you are interested in and start thinking what and where needs to be changed in order to implement it. If you have specific questions as you go about it, feel free to ask on this mailing list or on IRC. > Also, are bugs in https://gcc.gnu.org/wiki/EasyHacks good > beginning or not? The page itself is unfortunately very outdated. However, the link to the bugzilla search near its top might still be useful. While it definitely helps, we do not strictly require applicants to do any "easy hacks" or patch submissions prior to application. The main reason is that there are not as many opportunities for truly easy fixes and improvements as other projects might have. Still, feel free to pursue one, it can only help! Good luck! Martin
Re: Help needed with maintainer-mode
On Thu, 29 Feb 2024 at 20:49, Thiago Jung Bauermann wrote: > > > Hello, > > Christophe Lyon writes: > > > I hoped improving this would be as simple as adding > > --enable-maintainer-mode when configuring, after making sure > > autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's > > libtool and gettext seems OK). > > > > However, doing so triggered several problems, which look like race > > conditions in the build system (we build at -j160): > > - random build errors in binutils / gdb with messages like "No rule to > > make target 'po/BLD-POTFILES.in". I managed to reproduce something > > similar manually once, I noticed an empty Makefile; the build logs are > > of course difficult to read, so I couldn't figure out yet what could > > cause this. > > > > - random build failures in gcc in fixincludes. I think this is a race > > condition because fixincludes is updated concurrently both from > > /fixincludes and $buillddir/fixincludes. Probably fixable in gcc > > Makefiles. > > > > - I've seen other errors when building gcc like > > configure.ac:25: error: possibly undefined macro: AM_ENABLE_MULTILIB > > from libquadmath. I haven't investigated this yet. > > I don't know about the last one, but regarding the race conditions, one > workaround might be to define a make target that regenerates all files > (if one doesn't exist already, I don't know) and make the CI call it > with -j1 to avoid concurrency, and then do the regular build step with > -j160. > Yes, that's what I meant below with "magic" make target ;-) Thanks, Christophe > -- > Thiago
