Hi Steve, Thank you sincerely for explaining the implementation and project details. I will draft the proposal shortly and would appreciate discussing refinements with you before the deadline.
Yuao ________________________________ From: Steve Kargl <s...@troutmask.apl.washington.edu> Sent: Friday, March 28, 2025 1:35 To: Yuao Ma <c...@outlook.com> Cc: fortran@gcc.gnu.org <fortran@gcc.gnu.org> Subject: Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope On Thu, Mar 27, 2025 at 03:43:49PM +0000, Yuao Ma wrote: > > Thanks for sharing more details. I’ve realized that implementing half-cycle > trig functions can be quite tricky. If I get the chance to refine the patch, > I’d like to go through each function one by one (if the reviewers don’t mind), > since I’m new to the GCC project. If you pursue the half-cycle trig functions, I'll suggest that you start by reading the patch I attached to the bug report. https://gcc.gnu.org/bugzilla/attachment.cgi?id=57179 > I’m also not entirely sure about using libm directly for the math functions. > LLVM’s constant folding approach does this, but it has already shown some > drawbacks because libc and libm can behave differently across platforms—both > in > terms of actual results and linking. Using MPFR might provide more consistent > outcomes, and I’m open to further discussion on the implementation details. There are a few things here to unravel. First, for constant folding, gfortran uses MPFR. Newer versions of MPFR actually contain support for these functions, but GCC can be built with older versions of MPFR. Look in the patch for changes to simplify.cc. Second, run-time support is complicated by whether an operating system's libm provides these functions or not. If yes, gfortran should use the libm versions. If no, gfortran will need to use fallback implementations. I do not recall all of the details, but I had the frontend generating direct calls to libm function names and hoped to use weak symbols in libgfortran to get the desired functions. I could not find a solutions for static linking. So, I am inclined to redesign how I tried to handle the runtime to have everything go through libgfortran. For example, we would have (in pseudocode) _gfortran_sinpi(x) { #if HAVE_SINPI return (sinpi(x)); /* Call libm's sinpi */ #else fallback implementation #endif } Hopefully, LTO can remove the one level of indirection for the libm call. > Regarding GSoC, I think “Extracting tokens from a string,” > “Interoperability with C,” and “Trig function changes” could > be good fits for me. If you agree, I can start drafting a proposal. > Could you please let me know who might be available to mentor this > project? How many hours are available under a GSOC project? I think selecting only one of the above three topics would be sufficient. The first one, "Extracting...", may be the easiest, but does require one to deal with both the default character kind (aka ASCII) and gfortran's UTF-8 character kind. I know very little about UTF-8, so would be of little help. The third one, "Trig..." can leverage my initial patch, so you have a starting a point and someone who can provide some advice. -- Steve
