Re: P2996R2
On Sun, 24 Mar 2024, 23:07 Jeffrey Cliff via Gcc, wrote: > i notice P2996R2 ( > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2996r2.html > ) isn't listed yet in > https://gcc.gnu.org/projects/cxx-status.html#cxx26 > i'm assuming it's not implemented yet but not sure where to suggest > that that particular chart include it > is this the place? what is the policy for reporting C++2n P > proposals for inclusion on it? > That proposal is still making its way through the C++ committee and is not close to being approved yet. When it's approved for inclusion in the C++ working draft then it will be appropriate to add to that page.
Sourceware 2024 - The Plan
The Sourceware Project Leadership Committee in discussion with the Software Freedom Conservancy staff came up with the Sourceware 2024 plan and is looking at longer term projects that would be needed to keep your infrastructure running smoothly and securely for the next couple of years. We are currently discussing how to distribute these tasks over paid staff, overseers, project admin volunteers and contractors. We realize that our plans may not be your plans, so really like to get feedback. It is our goal to offer a worry-free, friendly home for Free Software core toolchain and developer tools projects. So please do reach out and share your ideas on the overseers mailinglist, file infrastructure bugs, join our channel #overseers on irc or join one of the monthly open office hours: https://sourceware.org/mission.html#organization For 2024 we want to concentrate on isolating and scaling the services. In the last two years we doubled the number of machines (and more are on the way!) that we run the services on. And some of the new services are already setup in containers or on isolated VMs. But most of the services are still isolated through traditional unix mechanisms. Moving those into their own container or VM will help scaling by making it easy to move between separate physical machines. It will also provide security in depth. It is our preference to run distro packaged software (e.g. mailman, postfix, public-inbox, etc.). That way we have easy security updates. But for some services we track an upstream stable branch (e.g. buildbot, patchwork and bugzilla). While isolating/containerizing these services we will also publish the internal git repos (if they contain any local adjustments), so we can easier share patches with other organizations. Ideally we'll also publish ansible playbooks. That way, over time, we will provide services that anybody can replicate and setup themselves. Longer term we identified a couple of thing, mainly around isolation (the theme of 2024), email, spam, mailinglists, search, AI bots and services upgrades that we believe are important to prepare for. Concretely we are looking at: - mailman2 upgrade/replacement https://sourceware.org/bugzilla/show_bug.cgi?id=31545 - bugzilla upgrade https://sourceware.org/bugzilla/show_bug.cgi?id=31547 - (local) search and AI bot/spiders, sitemaps, ... https://sourceware.org/bugzilla/show_bug.cgi?id=31551 https://sourceware.org/bugzilla/show_bug.cgi?id=31548 https://sourceware.org/bugzilla/show_bug.cgi?id=30610 https://sourceware.org/bugzilla/show_bug.cgi?id=31549 - Distributed spam fighting https://sourceware.org/bugzilla/show_bug.cgi?id=31550 - buildbot email templates, pre-commit testing, buildbot-travis, ... https://sourceware.org/bugzilla/show_bug.cgi?id=31552 More items can be found in the Sourceware infrastructure bugzilla https://sourceware.org/bugzilla/buglist.cgi?component=Infrastructure&product=sourceware&resolution=--- If you read this far we really like your feedback, even if it is a simple "OK!", Reply-To: overse...@sourceware.org Or add you comments to the bugzilla items above. And take a look at other ways to participate https://sourceware.org/mission.html#organization You can also help by becoming a Conservancy Sustainer https://sfconservancy.org/sustainer/ or donating directly to Sourceware https://sourceware.org/donate.html Thanks, Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, Mark J. Wielaard, Elena Zannoni
Re: [RFC] add regenerate Makefile target
On Thu, 21 Mar 2024 at 15:32, Christophe Lyon wrote: > > On Wed, 20 Mar 2024 at 16:34, Simon Marchi wrote: > > > > On 3/18/24 13:25, Christophe Lyon wrote: > > > Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit > > > more complex > > > than just calling automake. IIUC it calls automake --foreign it any of > > > *.m4 file from $(am__configure_deps) that is newer than Makefile.in > > > (with an early exit in the loop), does nothing if Makefile.am or > > > doc/local.mk are newer than Makefile.in, and then calls 'automake > > > --foreign Makefile' > > > > The rules looks complex because they've been generated by automake, this > > Makefile.in is not written by hand. And I guess automake has put > > `--foreign` there because foreign is used in Makefile.am: > Yes, I know :-) > > > > > AUTOMAKE_OPTIONS = foreign no-dist > > > > But a simple call so `automake -f` (or `autoreconf -f`) just works, as > > automake picks up the foreign option from AUTOMAKE_OPTIONS, so a human > > or an external script who wants to regenerate things would probably just > > use that. > > Indeed. I guess my concern is: if some change happens to > Makefile.am/Makefile.in which would imply that 'autoreconf -f' would > not work, how do we make sure autoregen.py (or whatever script) is > updated accordingly? Or maybe whatever change is made to > Makefile.am/Makefile.in, 'autoreconf -f' is supposed to handle it > without additional flag? > I think I've just noticed a variant of this: if you look at opcodes/Makefile.in, you can see that aclocal.m4 depends on configure.ac (among others). So if configure.ac is updated, a maintainer-mode rule in Makefile.in will call aclocal and regenerate aclocal.m4. However, autoregen.py calls aclocal only if configure.ac contains AC_CONFIG_MACRO_DIRS, which is not the case here. That's probably a bug in opcode/configure.ac, but still the current Makefile.in machinery would update aclocal.m4 as needed when autoregen.py will not. I haven't audited all configure.ac but there are probably other occurrences of this. Christophe > > > > > The bot I want to put in place would regenerate things as they are > > > supposed to be, then build and run the testsuite to make sure that > > > what is supposed to be committed would work (if the committer > > > regenerates everything correctly) > > > > For your job, would it be fine to just force-regenerate everything and > > ignore timestamps (just like the buildbot's autoregen job wants to do)? > > It would waste a few cycles, but it would be much simpler. > > > Yes, that would achieve the purpose: be able to handle as many patches > as possible in precommit-CI. > And as described earlier, for binutils this currently means: > autoregen > confgure --enable-maintainer-mode > make all (with a low -j value otherwise we have random build failures) > and my proposal to workaround the problem with -j is to do > make all-bfd all-libiberty regenerate -j1 > make all -j XXX > > Another possibility would be a policy change in how patches are > submitted, to require that they contain all the autogenerated files. > > > > Simon
Re: Interest in Contributing to OpenACC Support & Code Offloading Projects for GSOC
Hello, On Thu, Mar 21 2024, Soumya Ranjan via Gcc wrote: > Hello, > > I hope this message finds you well. My name is Soumya Ranjan, and I hold a > Bachelor's degree in Electrical Engineering and a Master's in Computer > Engineering. I am currently working as a Firmware Engineer at Qualcomm > Wireless R&D. I recently discovered your organization and the exciting GSOC > projects you are proposing, namely "Offloading to a separate process on the > same host" and "Enhance OpenACC support." I am writing to express my > enthusiastic interest in potentially contributing to either of these > projects and to inquire about the next steps to formally apply or draft a > proposal. The above suggests you are no longer a full time student (but then your email address indicates you might be :-) so I suppose you fulfill the 7.1.(a).iv clause of GSoC rules by being a "beginner to open source software development." If so, we are delighted that you decided to start your FOSS journey with us. > > My academic journey was enriched with substantial coursework in operating > systems and parallel computing, sparking a deep interest in efficient > computational strategies and optimizations. My professional experience has > further developed my skills in C/C++, offloading compilation, and > inter-process communication. Given this foundation, I am confident in my > capacity to make a meaningful contribution to either the project focused on > enhancing debugging capabilities for offloaded code or the one aimed at > filling the existing gaps in OpenACC support, depending on where my skills > can be best utilized. > > I realize I am reaching out at a time when proposals are likely already > underway. I apologize for this timing and am committed to diligently > catching up. I've started to familiarize myself with the "Before You Apply" > guidelines on your website to ensure I understand the necessary preparatory > steps. > > Could you kindly advise if there are any additional specific steps I should > follow or particular aspects of either project you would recommend focusing > on in my proposal? The prospect of contributing to advancements in either > domain is highly motivating to me, and I am keen to align my efforts with > the project's most pressing needs. The generic steps are listed in the "Before You Apply" guidelines. As far as the "Offloading to a separate process" project is concerned, please have a look at a recent discussions in the mailing list archive, specifically at - https://gcc.gnu.org/pipermail/gcc/2024-March/243462.html and - https://gcc.gnu.org/pipermail/gcc/2024-March/243478.html As far as I can tell, the project on enhancing the OpenACC has not been discussed yet. I am not really familiar with OpenACC myself, so can only give rudimentary advice. First, I'd make sure that I know what the routines/directives that need to be implemented do. Second, I'd then find some basic OpenACC testcase and do a similar experiment as described in the email messages linked above (but perhaps with -fdump-tree-all and not just -fdump-tree-optimize). That should give you an idea where to look next. Please feel free to ask here on the mailing list for help with any specific technical issue or question you encounter. > I am eager to learn more about how I can integrate into your team and > contribute effectively. I believe this opportunity aligns perfectly with my > professional aspirations and skills, and I am excited about the potential > collaboration. Given the timing, I'd focus on the proposal. The key should be to convince us that you have the ability to complete the project. I.e. that you understand what needs to be done and have a rough idea - a very rough but mostly correct idea - what and where needs to be changed to do so. Good luck! Martin > > Thank you very much for considering my application. I look forward to the > opportunity to further discuss how I can contribute to the success of your > project. > > Warm regards, > Soumya Ranjan
Re: GSoC
On Sat, Mar 23 2024, koushiki khobare via Gcc wrote: > Respected sir, > > I am Koushiki Khobare from India and currently a first year > student(Computer Science Student) studying in Pune Institute of > Computer Technology, Pune, Maharashtra. Recently I heard about GSoC > and got very excited to explore it. I will be very much thankful to > you if you provide me some guidance and help me to explore more. I > have learnt C programming language. So I visited your projects and > they were all amazing and quite interesting to work upon. We are delighted you found contributing to GCC interesting. Please note that apart from C (and C++!) coding skills, most projects require some rudimentary theoretical background in compilers. > One of them > I am thinking to explore is “Rust Front End”.So I will be grateful to > work with all my mentors- Mr.Pierre-Emmaunel Patry, Mr. Philip Herron, > Mr.Arthur Cohen, all being excellent in their works. 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 them there as well. > I will be so much > of grateful if I get to know what actual skills do you expect from me > apart from mentioned on website and guide me with what all do I need > to do in my proposal. The skills mentioned on the website (i.e. https://gcc.gnu.org/wiki/SummerOfCode ) should be quite sufficient. I can only advise that you look at the "Before you apply" section and take (most of) the steps described there. > I request you to provide me some guidance with my proposal. You need to select a particular project and make at least a few first steps (again, at look at those described at https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply ) yourself. Then we can help you to polish things up. Good luck! Martin Jambor
Re: "GSoC"
Hello, On Sun, Mar 24 2024, M Hamza Nadeem via Gcc wrote: > Hi Sir / mam, > > > I hope this email finds you well. As an enthusiastic contributor with a > strong grasp of C/C++ and familiarity with Rust, I am eager to explore > potential projects for Google Summer of Code (GSoC) 2024 within the GNU > Compiler Collection (GCC) ecosystem. we are delighted you found the prospect of contributing to GCC interesting. > > With my background in these languages and my passion for advancing compiler > technology, I believe I could make significant contributions to various GCC > projects. > > I would greatly appreciate any guidance on how to proceed further with > project selection or any additional insights into the GCC projects relevant > to my skill set. Please look again at the "Before you apply" section of our GSoC page at https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you are able to build, install and test GCC. I strongly suggest that you also try generating dumps of the IR of a simple compiled program and stepping through some function during compilation in a debugger. Afterwards, look at the suggested projects, try to identify the portion of GCC source where it needs to be implemented and think about how. Then email us back to this mailing list describing your current plan together with any technical questions you'd like to have answered to proceed further. We'll be happy to help. Good luck, Martin
Re: "GSoC"
Thanks, I'll check them out. On Mon, 25 Mar 2024, 9:50 pm Martin Jambor, wrote: > Hello, > > On Sun, Mar 24 2024, M Hamza Nadeem via Gcc wrote: > > Hi Sir / mam, > > > > > > I hope this email finds you well. As an enthusiastic contributor with a > > strong grasp of C/C++ and familiarity with Rust, I am eager to explore > > potential projects for Google Summer of Code (GSoC) 2024 within the GNU > > Compiler Collection (GCC) ecosystem. > > we are delighted you found the prospect of contributing to GCC interesting. > > > > > With my background in these languages and my passion for advancing > compiler > > technology, I believe I could make significant contributions to various > GCC > > projects. > > > > I would greatly appreciate any guidance on how to proceed further with > > project selection or any additional insights into the GCC projects > relevant > > to my skill set. > > Please look again at the "Before you apply" section of our GSoC page at > https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you > are > able to build, install and test GCC. I strongly suggest that you also try > generating dumps of the IR of a simple compiled program and stepping > through > some function during compilation in a debugger. > > Afterwards, look at the suggested projects, try to identify the portion of > GCC > source where it needs to be implemented and think about how. Then email us > back to this mailing list describing your current plan together with any > technical questions you'd like to have answered to proceed further. We'll > be > happy to help. > > Good luck, > > Martin > >
AutoFDO tools for GCC
Hello, I've been the AutoFDO maintainer for the last 1.5 years. I've resurrected autoprofiledbootstrap build and made a number of other fixes/improvements (e.g., discriminator support). The tools for AutoFDO (create_gcov, etc.) currently live in https://github.com/google/AutoFDO repo and GCC AutoFDO documentation points users to that repo. That repo also has tools for LLVM AutoFDO. https://github.com/google/AutoFDO has several submodules: https://github.com/google/autofdo/blob/master/.gitmodules I got a message from Snehasish (cc'd) that google intends to migrate the tools for LLVM to the LLVM repo and wants to archive https://github.com/google/AutoFDO. That will be a problem for AutoFDO in GCC. The idea to find a different home for GCC AutoFDO tools was discussed before on this alias but this becomes more urgent now. One idea was to build these tools from GCC repo and another was to produce gcov from perf tool directly. Andi (cc'd) had some early unfinished prototype for latter. Please let me know if you have thoughts on how we should proceed. Thanks, Eugene
unneeded spills of SF values on xtensa with FPU
Hi Suwa-san,
I've noticed that in xtensa configurations with hardware FPU
function arguments of type float are spilled on the stack although
there's no need for that. E.g. the following function:
int f(float a, float b)
{
return a < b;
}
translates to the following with -O2:
f:
entry sp, 48
wfr f0, a2
wfr f1, a3
s32i.n a2, sp, 0
olt.s b0, f0, f1
movi.n a8, 0
movi.n a2, 1
s32i.n a3, sp, 4
movfa2, a8, b0
retw.n
The relevant RTL looks like this at the end of IRA:
(insn 18 4 19 2 (set (reg:SF 51)
(reg:SF 2 a2 [ a ])) "test2.c":2:1 61 {movsf_internal}
(expr_list:REG_DEAD (reg:SF 2 a2 [ a ])
(nil)))
(insn 19 18 7 2 (set (reg:SF 52)
(reg:SF 3 a3 [ b ])) "test2.c":2:1 61 {movsf_internal}
(expr_list:REG_DEAD (reg:SF 3 a3 [ b ])
(nil)))
(insn 7 19 21 2 (set (reg:CC 18 b0)
(lt:CC (reg:SF 51)
(reg:SF 52))) "test2.c":3:11 100 {slt_sf}
(expr_list:REG_DEAD (reg:SF 52)
(expr_list:REG_DEAD (reg:SF 51)
(nil
and it is transformed to the following by the end of LRA:
(insn 18 4 19 2 (set (mem/c:SF (reg/f:SI 1 sp) [1 %sfp+0 S4 A32])
(reg:SF 2 a2 [ a ])) "test2.c":2:1 61 {movsf_internal}
(nil))
(insn 19 18 24 2 (set (mem/c:SF (plus:SI (reg/f:SI 1 sp)
(const_int 4 [0x4])) [1 %sfp+4 S4 A32])
(reg:SF 3 a3 [ b ])) "test2.c":2:1 61 {movsf_internal}
(nil))
(insn 24 19 25 2 (set (reg:SF 19 f0 [51])
(mem/c:SF (reg/f:SI 1 sp) [1 %sfp+0 S4 A32])) "test2.c":3:11 61
{movsf_internal}
(nil))
(insn 25 24 7 2 (set (reg:SF 20 f1 [52])
(mem/c:SF (plus:SI (reg/f:SI 1 sp)
(const_int 4 [0x4])) [1 %sfp+4 S4 A32])) "test2.c":3:11
61 {movsf_internal}
(nil))
(insn 7 25 21 2 (set (reg:CC 18 b0)
(lt:CC (reg:SF 19 f0 [51])
(reg:SF 20 f1 [52]))) "test2.c":3:11 100 {slt_sf}
(nil))
LRA stops checking alternatives for insns 18 and 19 at s32i.n,
but even if I move wfr at the head of the movsf_internal list it
still loses to s32i.n.
Postreload pass replaces the lsi instructions 24 and 25 with
wfr from a2 and a3, but doesn't remove the spills.
I wonder what can be done with that?
--
Thanks.
-- Max
