[GSoC]Fortran – run-time argument checking
Gwen Fu 于 2025年3月25日周二 下午8:34写道： > I found out that "-fcheck=*" is an option for runtime checking, but the > relevant options are commented out. > OPT_fcheck_ = 1070,/* -fcheck= */ > /* OPT_fcheck_assert = 1071, *//* -fcheck=assert */ > /* OPT_fcheck_bounds = 1072, *//* -fcheck=bounds */ > /* OPT_fcheck_in = 1073, *//* -fcheck=in */ > /* OPT_fcheck_invariant = 1074, */ /* -fcheck=invariant */ > /* OPT_fcheck_out = 1075, */ /* -fcheck=out */ > /* OPT_fcheck_switch = 1076, *//* -fcheck=switch */ > OPT_fcheckaction_ = 1077, /* -fcheckaction= */ > OPT_fchecking = 1078, /* -fchecking */ > > And I tried : > $ gfortran -o fibonacci fabonaqi.f90 -fcheck=in > f951: Warning: command-line option ‘-fpreconditions’ is valid for D but > not for Fortran > $ gfortran --help=check > cc1: warning: unrecognized argument to ‘--help=’ option: ‘check’ > So what's wrong with these ? >
Re: GSOC 2025 - Fortran - 2018/202x
Hello, we are delighted you found contributing to GCC interesting. On Mon, Mar 24 2025, Yuao Ma via Gcc wrote: > Hello GCC Community, > > My name is Yuao, and I’m excited to express my interest in the > “Fortran – 2018/202x” project for Google Summer of Code. I am majoring in > Cyber > Science and Engineering, with a solid background in computer science that I > believe will help me contribute effectively to this project. > > I am passionate about open-source software and have made contributions to > several projects, including vcpkg and LLVM. Within LLVM, I’ve worked on Clang > (the front-end), middle-end optimization passes, and llvm-libc. These > experiences have allowed me to develop a strong understanding of > production-grade compilers—expertise I hope to bring to the GCC Fortran > project. > > I would greatly appreciate any guidance or suggestions on how to get started, > such as relevant documentation, communication channels, or initial tasks. Our GSoC page at https://gcc.gnu.org/wiki/SummerOfCode should contain most of the information you are requesting. The best documents (and other steps to take) to get to know GCC are listed in the "Before you apply" section ( https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply ). You have already found the two mailing lists (the general one gcc and fortran ones) which are the most important communication channels. Another one is IRC which is also described on the page. There are no initial tasks, I'm afraid. But go over the "Before you apply" section 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. > Specifically, I would like to know which new features have been implemented > and > which are still pending in the GSoC project. All proposed projects in the "Selected Project Ideas" section ( https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas ) are still relevant and pending. Those in the "Other Project Ideas" section are a bit likely to be outdated, but feel free to ask about any specific one. > Additionally, I am interested in knowing which features are more > suitable or have higher priority for implementation. People more familiar with the Fortran FE might correct me if I am wrong, but as far as I know all the Fortran projects listed in the "Selected Project Ideas" have similar importance, so look at whichever looks more interesting to you. > Thank you for your time, and I look forward to the possibility of > working with you and learning from the GCC community. Good luck! Martin
Re: [Draft] GSoC 2025 Proposal: Implementing Clang's -ftime-trace Feature in GCC
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: [RISC-V] vector segment load/store width as a riscv_tune_param
On Wed, Mar 26, 2025 at 1:44 AM Robin Dapp wrote: > > You won't see failures in the testsuite. The failures only show-up when I > > attempt to impose huge costs on NF above threshold. A quick & dirty way > to > > expose the bug is apply the appended patch, then observe that you get > output > > from this only for mask_struct_store-*.c and not for mask_struct_load-*.c > > I suppose that's due to Richi's restructuring of the vector/SLP code. > What > might work is (untested): > It's a winner for my tests! Gracias. G
Re: [Draft] GSoC 2025 Proposal: Implementing Clang's -ftime-trace Feature in GCC
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... Jakub
Re: [RISC-V] vector segment load/store width as a riscv_tune_param
You won't see failures in the testsuite. The failures only show-up when I
attempt to impose huge costs on NF above threshold. A quick & dirty way to
expose the bug is apply the appended patch, then observe that you get output
from this only for mask_struct_store-*.c and not for mask_struct_load-*.c
I suppose that's due to Richi's restructuring of the vector/SLP code. What
might work is (untested):
diff --git a/gcc/config/riscv/riscv-vector-costs.cc
b/gcc/config/riscv/riscv-vector-costs.cc
index 167375ca751..3c8ff760a4e 100644
--- a/gcc/config/riscv/riscv-vector-costs.cc
+++ b/gcc/config/riscv/riscv-vector-costs.cc
@@ -1114,7 +1114,7 @@ segment_loadstore_group_size (enum vect_cost_for_stmt
kind,
unsigned
costs::adjust_stmt_cost (enum vect_cost_for_stmt kind, loop_vec_info loop,
stmt_vec_info stmt_info,
-slp_tree, tree vectype, int stmt_cost)
+slp_tree node, tree vectype, int stmt_cost)
{
const cpu_vector_cost *costs = get_vector_costs ();
switch (kind)
@@ -1138,6 +1138,8 @@ costs::adjust_stmt_cost (enum vect_cost_for_stmt kind,
loop_vec_info loop,
costs for each. */
/* TODO: Indexed and ordered/unordered cost. */
int group_size = segment_loadstore_group_size (kind, stmt_info);
+ if (!group_size && node->ldst_lanes)
+ group_size = node->lanes;
if (group_size > 1)
{
switch (group_size)
--
Regards
Robin
