GSoC mandatory step error
Dear Sir/Madam, I just wanted to ask about the build of gcc. I know it is a required step before applying to GCC for the GSoC 2025. However, I get an error. Here is the error: /home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/./prev-gcc/xg++ -B/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/./prev-gcc/ -B/home/stoplight/GitProjects/install_dir/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/stoplight/GitProjects/GCC-PROJECT/gcc/libstdc++-v3/libsupc++ -L/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -O -fno-checking -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -fno-PIE -I. -I. -I../../../gcc -I../../../gcc/. -I../../../gcc/../include -I../../../gcc/../libcpp/include -I../../../gcc/../libcody -I../../../gcc/../libdecnumber -I../../../gcc/../libdecnumber/bid -I../libdecnumber -I../../../gcc/../libbacktrace -o tree-tailcall.o -MT tree-tailcall.o -MMD -MP -MF ./.deps/tree-tailcall.TPo ../../../gcc/tree-tailcall.cc ../../../gcc/tree-tailcall.cc: In function ‘void find_tail_calls(basic_block, tailcall**, bool, bool&, bool)’: ../../../gcc/tree-tailcall.cc:612:27: error: ‘stmt’ may be used uninitialized [-Werror=maybe-uninitialized] 612 | if ((stmt_could_throw_p (cfun, stmt) |~~~^~~~ ../../../gcc/tree-tailcall.cc:480:11: note: ‘stmt’ was declared here 480 | gimple *stmt; | ^~~~ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:1210: tree-tailcall.o] Error 1 make[3]: Leaving directory '/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/gcc' make[2]: *** [Makefile:5116: all-stage2-gcc] Error 2 make[2]: Leaving directory '/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object' make[1]: *** [Makefile:25506: stage2-bubble] Error 2 make[1]: Leaving directory '/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object' make: *** [Makefile:25718: bootstrap] Error 2 ChatGPT doesn't seem to be able to fix it. I used this command for configure: ../../configure --prefix=$HOME/GCC-Project/install_dir --enable-languages=c,c++. I did this in a build/object folder in gcc folder. THe prefix is outside of the gcc folder. THen I ran make BOOT_CFLAGS='-O' bootstrap. I tried rerunning it with make CFLAGS="-Wno-error=maybe-uninitialized" CXXFLAGS="-Wno-error=maybe-uninitialized" BOOT_CFLAGS='-O' bootstrap, but it didn't work. Please let me know what I should do next. I really want to work for gcc this summer. Best Wishes, Leul Shiferaw
Re: [Draft] GSoC 2025 Proposal: Implementing Clang's -ftime-trace Feature in GCC
I wanted to follow up on my previous email regarding my interest in participating in Google Summer of Code with GCC. I saw the discussion in the thread, but it seems there was no final confirmation. Could you please let me know if everything is in order and whether I can proceed with submitting my application? I would really appreciate any guidance on the next steps. Looking forward to your response. ср, 26 мар. 2025 г. в 17:34, Sam James : > Jakub Jelinek via Gcc writes: > > > On Tue, Mar 25, 2025 at 07:21:32AM +0300, Eldar Kusdavletov via Gcc > wrote: > >> *Dear GCC Mentoring Team,* > >> I am writing to submit my proposal for the Google Summer of Code (GSoC) > >> 2025 program, aiming to contribute to the GCC project by implementing a > >> feature similar to Clang's -ftime-trace. This feature generates > performance > >> reports detailing the compiler's time distribution across various > >> compilation phases, providing valuable insights for optimization. > > > > How is that different from GCC's -ftime-report or -ftime-report-details? > > We've been tracking the time spent by different compilation phases for > the > > last 25 years... > > -ftime-report* gives overall timings on phases, it does not give a > line-by-line breakdown alongside the user's code. > > i.e. -ftime-trace helps to answer "which parts of my program are causing > slow compilation?" > > See https://gcc.gnu.org/PR92396. >
Re: Does gcc have different inlining heuristics on different platforms?
Thanks for the quick reply, I'll ask the people responsible for working on the Linux parts try to compile and link the codebase with -fno-use-linker-plugin to see what happens. It's a bit disheartening to hear that LTO support on Windows is behind Linux though. I'd help get that up to speed if I could, but I don't even know where to start or look :( best regards, Julian On Mon, Mar 31, 2025 at 8:09 PM Richard Biener wrote: > > On Mon, Mar 31, 2025 at 1:20 PM Julian Waters via Gcc wrote: > > > > Hi all, > > > > I've been trying to chase down an issue that's been driving me insane > > for a while now. It has to do with the flatten attribute being > > combined with LTO. I've heard that flatten and LTO are a match made in > > hell (Someone else's words, not mine), but from what I observe, > > several methods marked as flatten on Linux compile to an acceptable > > size with ok amount of inlining, but on Windows however... The exact > > same methods marked as flatten have their callees inlined so > > aggressively that they reach sizes of 5MB per method! Something seems > > to be different between how inlining works on the 2 platforms, what > > are the differences (If any) between Linux and Windows when it comes > > to inlining, particularly involving the flatten attribute? Is there a > > list of differences that is easily accessible somewhere, or > > alternatively is there somewhere in the gcc source where the > > heuristics are defined that I can decipher? > > > > Here's one such example of the differences between Linux and Windows > > (Both were compiled with the same optimization settings, -O3 and > > -flto=auto): > > > > Linux: > > 010b12d0 6289 t > > G1ParScanThreadState::trim_queue_to_threshold(unsigned int) > > > > Windows: > > 000296f9b0c0 00642d40 T > > G1ParScanThreadState::trim_queue_to_threshold(unsigned int) [clone > > .constprop.0] > > 000295125480 00630080 T > > G1ParScanThreadState::trim_queue_to_threshold(unsigned int) > > > > > > Thanks in advance for the help, and for humouring my question > > The main difference is that LTO on Linux can use the linker plugin > to derive information about how TUs are combined while on Windows > we're using the "collect2 path" which is quite unmaintained and which > gives imprecise information. This can already result in quite different > inlining. You can "simulated" that on Linux with -fno-use-linker-plugin > (only for experimenting, don't use this unless necssary). > > Richard. > > > > > best regards, > > Julian
GSoC 2025 – Excited About GCC Go Escape Analysis & Seeking Guidance
I hope you're doing well! I'm incredibly excited about the "GCC Go Escape Analysis" project for GSoC 2025. I've spent time reviewing past contributions, including the 2024 work related to Go in GCC, and I’m eager to build on that progress in a meaningful way. After going through the mailing lists and discussions, I want to ensure my initial contributions align with the current priorities of the project. Could you please guide me on the type of bug fixes or improvements that would be most valuable at this stage? I want to focus on something impactful that contributes to the project’s long-term goals. Looking forward to your insights, and I truly appreciate your time and guidance! Best regards, Astha Pipania
Does gcc have different inlining heuristics on different platforms?
Hi all, I've been trying to chase down an issue that's been driving me insane for a while now. It has to do with the flatten attribute being combined with LTO. I've heard that flatten and LTO are a match made in hell (Someone else's words, not mine), but from what I observe, several methods marked as flatten on Linux compile to an acceptable size with ok amount of inlining, but on Windows however... The exact same methods marked as flatten have their callees inlined so aggressively that they reach sizes of 5MB per method! Something seems to be different between how inlining works on the 2 platforms, what are the differences (If any) between Linux and Windows when it comes to inlining, particularly involving the flatten attribute? Is there a list of differences that is easily accessible somewhere, or alternatively is there somewhere in the gcc source where the heuristics are defined that I can decipher? Here's one such example of the differences between Linux and Windows (Both were compiled with the same optimization settings, -O3 and -flto=auto): Linux: 010b12d0 6289 t G1ParScanThreadState::trim_queue_to_threshold(unsigned int) Windows: 000296f9b0c0 00642d40 T G1ParScanThreadState::trim_queue_to_threshold(unsigned int) [clone .constprop.0] 000295125480 00630080 T G1ParScanThreadState::trim_queue_to_threshold(unsigned int) Thanks in advance for the help, and for humouring my question best regards, Julian
