[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 Fortran – 2018/202x – Inquiry About Project Scope
Yuao, I do not intend to be a mentor. I will however answer questions and review patches posted to fort...@gnu.gcc.org. I suspect that the half-cycle trigs functions will be a challenging GSOC project. But, if you're successful, then you'll be well prepared to continue contributing to gfortran. Besides the issue with using functions supplied by an OS's libm or fallback functions in libgfortran, you'll need to develop some method to deal with atanpi(x) and atanpi(y,x). The method currently used for atan(x) and atan(y,x) is (IMNSHO) somewhat of a kludge. -- steve On Wed, Mar 26, 2025 at 04:13:38PM +, Yuao Ma wrote: > Hi Steve, > > Thank you for your feedback! Are you going to mentor this specific Fortran > GSoC > project? You mentioned having a draft patch, and I would like to refine it as > a > starting point for the project! > > Yuao > > From: Steve Kargl > Sent: Tuesday, March 25, 2025 2:25 > To: Yuao Ma > Cc: fortran@gcc.gnu.org > Subject: Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope > > I've already written a prototype of the half-cycle trig > functions. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 > > There are two issues that need to be address. First, some > operating systems provide half-cycle trig functions in their > libm. The initial patch tries to use libm functions if > found, but in hindsight I think gfortran should simply > provide its own implementations. Second, the patch needs > to be cleaned up and rigorously tested. I haven't had time > to do this. > > If you are looking for a relatively small and well-defined > project, I'll suggest looking at implementations for the > new intrinsic subprograms SPLIT() and TOKENIZE(). As far as > I know, no one is working on these routines. > > -- > steve > > On Mon, Mar 24, 2025 at 04:45:06PM +, Yuao Ma wrote: > > Hello GCC Community, > > > > I hope this message finds you well. My name is Yuao, and I’m excited to > > express > > my interest in the "Fortran – 2018/202x" project for Google Summer of Code. > > I’m > > writing to clarify the scope of this project and gather any recommendations > > you > > may have. > > > > >From the project documentation and the "What's New in 202x" resources, I > > understand that “Extracting tokens from a string,” “Interoperability with > > C,” > > and “Trig function changes” would be considered a medium-sized undertaking. > > After exploring the codebase, I noticed that trigonometric functions > > working in > > degrees have already been implemented. I’d be very interested in continuing > > with the half-revolution functionality as well as addressing the “Changes > > for > > conformance with the new IEEE standard.” I’d love to hear your thoughts on > > whether this focus is aligned with current project needs or if there are > > other > > areas you recommend I prioritize. > > > > Thank you for your time and guidance. I look forward to your feedback on > > how I > > can best contribute. > > > > Kind regards, > > Yuao > > -- > Steve -- Steve
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: [PATCH] Fortran: fix bogus recursion with DT default initialization [PR118796]
Hi Andre, Am 26.03.25 um 22:49 schrieb Andre Vehreschild: Hi Harald, looks good to me. Thanks for the patch. pushed as r15-8945-gb70bd691cfd77b. Thanks for the swift review! Harald - Andre Andre Vehreschild * ve...@gmx.de Am 26. März 2025 22:18:41 schrieb Harald Anlauf : Dear all, it seems that my patch for default-initialization of function results of derived type could trigger a weird issue if a type-bound function of a type that is use-associated from a different module had the same name, even if the declared function had a different type, but only if the result clause is present. While I had hoped that resolution should not lead to this situation, checking whether the function was use-associated solved the issue. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald
Re: [PATCH] Fortran: fix bogus recursion with DT default initialization [PR118796]
Hi Harald, looks good to me. Thanks for the patch. - Andre Andre Vehreschild * ve...@gmx.de Am 26. März 2025 22:18:41 schrieb Harald Anlauf : Dear all, it seems that my patch for default-initialization of function results of derived type could trigger a weird issue if a type-bound function of a type that is use-associated from a different module had the same name, even if the declared function had a different type, but only if the result clause is present. While I had hoped that resolution should not lead to this situation, checking whether the function was use-associated solved the issue. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald
Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope
Hi Steve, Thank you for your feedback! Are you going to mentor this specific Fortran GSoC project? You mentioned having a draft patch, and I would like to refine it as a starting point for the project! Yuao From: Steve Kargl Sent: Tuesday, March 25, 2025 2:25 To: Yuao Ma Cc: fortran@gcc.gnu.org Subject: Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope I've already written a prototype of the half-cycle trig functions. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 There are two issues that need to be address. First, some operating systems provide half-cycle trig functions in their libm. The initial patch tries to use libm functions if found, but in hindsight I think gfortran should simply provide its own implementations. Second, the patch needs to be cleaned up and rigorously tested. I haven't had time to do this. If you are looking for a relatively small and well-defined project, I'll suggest looking at implementations for the new intrinsic subprograms SPLIT() and TOKENIZE(). As far as I know, no one is working on these routines. -- steve On Mon, Mar 24, 2025 at 04:45:06PM +, Yuao Ma wrote: > Hello GCC Community, > > I hope this message finds you well. My name is Yuao, and I’m excited to > express > my interest in the "Fortran – 2018/202x" project for Google Summer of Code. > I’m > writing to clarify the scope of this project and gather any recommendations > you > may have. > > >From the project documentation and the "What's New in 202x" resources, I > understand that “Extracting tokens from a string,” “Interoperability with C,” > and “Trig function changes” would be considered a medium-sized undertaking. > After exploring the codebase, I noticed that trigonometric functions working > in > degrees have already been implemented. I’d be very interested in continuing > with the half-revolution functionality as well as addressing the “Changes for > conformance with the new IEEE standard.” I’d love to hear your thoughts on > whether this focus is aligned with current project needs or if there are other > areas you recommend I prioritize. > > Thank you for your time and guidance. I look forward to your feedback on how I > can best contribute. > > Kind regards, > Yuao -- Steve
[PATCH] Fortran: fix bogus recursion with DT default initialization [PR118796]
Dear all,
it seems that my patch for default-initialization of function results
of derived type could trigger a weird issue if a type-bound function
of a type that is use-associated from a different module had the
same name, even if the declared function had a different type, but
only if the result clause is present.
While I had hoped that resolution should not lead to this situation,
checking whether the function was use-associated solved the issue.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 0cfeedf5865cd781478b4652477009ca05f4de77 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 26 Mar 2025 22:04:39 +0100
Subject: [PATCH] Fortran: fix bogus recursion with DT default initialization
[PR118796]
PR fortran/118796
gcc/fortran/ChangeLog:
* resolve.cc: Do not apply default initialization to a derived-type
function result if the resolved function is use-associated.
gcc/testsuite/ChangeLog:
* gfortran.dg/derived_result_4.f90: New test.
---
gcc/fortran/resolve.cc| 3 +-
.../gfortran.dg/derived_result_4.f90 | 38 +++
2 files changed, 40 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/derived_result_4.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index cf9318ff763..cb3658917ef 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -17946,7 +17946,8 @@ skip_interfaces:
/* Mark the result symbol to be referenced, when it has allocatable
components. */
sym->result->attr.referenced = 1;
- else if (a->function && !a->pointer && !a->allocatable && sym->result)
+ else if (a->function && !a->pointer && !a->allocatable && !a->use_assoc
+ && sym->result)
/* Default initialization for function results. */
apply_default_init (sym->result);
}
diff --git a/gcc/testsuite/gfortran.dg/derived_result_4.f90 b/gcc/testsuite/gfortran.dg/derived_result_4.f90
new file mode 100644
index 000..12ab1909492
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/derived_result_4.f90
@@ -0,0 +1,38 @@
+! { dg-do compile }
+! { dg-additional-options "-Wall -Wno-return-type -Wno-unused-variable" }
+!
+! PR fortran/118796 - bogus recursion with DT default initialization
+
+module m1
+ implicit none
+
+ type :: t1
+ type(integer) :: f1 = 0
+ end type t1
+
+ TYPE :: c1
+ contains
+ procedure, public :: z
+ END TYPE c1
+
+contains
+ ! type-bound procedure z has a default initialization
+ function z( this )
+type(t1) :: z
+class(c1), intent(in) :: this
+ end function z
+end module m1
+
+module m2
+ use m1, only : c1
+contains
+ function z() result(field)
+ end function z
+end module m2
+
+module m3
+ use m1, only : c1
+contains
+ function z()
+ end function z
+end module m3
--
2.43.0
