Re: [Patch, Fortran] C prototypes for functions returning C function pointers
Hello Harald, OK with the above addressed. Both addressed and pushed in https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=737a5760bb24a0a945cc2c916ba452e3f0060c58 Thanks for the review (and for catching the miscellaneous problems on the way)! Best regards Thomas
Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope
Hi Steve, 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. 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. 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? Thanks! Yuao From: Steve Kargl Sent: Thursday, March 27, 2025 2:15 To: Yuao Ma Cc: fortran@gcc.gnu.org Subject: 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: [PATCH] testsuite: Replace the cray_pointers_2.f90 no cycling hack with dg-skip-if
On Thu, Mar 27, 2025 at 07:34:14PM +0100, Jakub Jelinek wrote:
> The following patch runs the test only in the -O3 -g case (just using -O3
> there would run it twice, once with
> -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
> -finline-functions
> and once with
> -O3 -g
>
> The -O3 from dg-options can be dropped too.
>
> Some tests (e.g. in testsuite/gcc.dg/torture/) use e.g.
> /* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O2" } } */
> so the test is run just with -O2 by default, but when testing with
> GCC_TEST_RUN_EXPENSIVE=1 it cycles through everything. Note, you'd need
> to drop the -O3 from dg-options in that case for sure, because with explicit
> -O3 option in there it cycles through -O0 -O3, -O1 -O3, -O2 -O3,
> -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
> -finline-functions -O3,
> -O3 -g -O3, -Os -O3.
Though, seeing 395 gfortran.dg/*.f90 tests with dg-options or
dg-additional-options including -O, perhaps better might be to hack up
the gfortran.dg/dg.exp and libgomp.fortran/fortran.exp drivers so that
they actually don't cycle through options if -O appears anywhere in
dg-options/dg-additional-options.
What do you think about that?
For gcc.dg/torture/ and g++.dg/torture/, IMHO explicit -O in
dg-options/dg-additional-options is always a bug, either the test shouldn't
be in torture subdirectory and have the explicit -O, or it shouldn't have
them and cycle through everything.
But in gfortran.dg case when the default is to cycle for all tests...
Jakub
Re: [PATCH] testsuite: Replace the cray_pointers_2.f90 no cycling hack with dg-skip-if
Hi Jakub, all,
Am 27.03.25 um 20:04 schrieb Jakub Jelinek:
On Thu, Mar 27, 2025 at 07:34:14PM +0100, Jakub Jelinek wrote:
The following patch runs the test only in the -O3 -g case (just using -O3
there would run it twice, once with
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
and once with
-O3 -g
The -O3 from dg-options can be dropped too.
Some tests (e.g. in testsuite/gcc.dg/torture/) use e.g.
/* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O2" } } */
so the test is run just with -O2 by default, but when testing with
GCC_TEST_RUN_EXPENSIVE=1 it cycles through everything. Note, you'd need
to drop the -O3 from dg-options in that case for sure, because with explicit
-O3 option in there it cycles through -O0 -O3, -O1 -O3, -O2 -O3,
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions -O3,
-O3 -g -O3, -Os -O3.
Though, seeing 395 gfortran.dg/*.f90 tests with dg-options or
dg-additional-options including -O, perhaps better might be to hack up
the gfortran.dg/dg.exp and libgomp.fortran/fortran.exp drivers so that
they actually don't cycle through options if -O appears anywhere in
dg-options/dg-additional-options.
What do you think about that?
For gcc.dg/torture/ and g++.dg/torture/, IMHO explicit -O in
dg-options/dg-additional-options is always a bug, either the test shouldn't
be in torture subdirectory and have the explicit -O, or it shouldn't have
them and cycle through everything.
But in gfortran.dg case when the default is to cycle for all tests...
I don't think we want to change the default for gfortran.dg,
at least not now. And not in any of the subdirectories, which
I normally do not touch.
It would be great to have an easy-to-use way to run selected tests
only once, for the following reasons (just my opinion):
(1) A certain runtime test is expensive. Here I did not know that there
is a variable GCC_TEST_RUN_EXPENSIVE, but this seems to suppress
running a certain test completely. This may be too much, and it
appears that gfortran.dg does not yet support this.
(2) A certain runtime test actually tests the runtime *library*.
Cycling through options then provides no insight and is just a
waste of my time as voluntary developer. The only way to cycle
here I can imagine would involve e.g. lto.
(3) ...
I like the idea of having a way to control how expensive tests
can be. For example, several of the tests that check inline code
generation in the Fortran FE would need only a small subset of
the options being tested in regtesting, unless one really works
on that particular Frontend code in question.
It would be really helpful to have an easy-to-use way to specify
if a test should cycle over options, or just one, (or a list?).
Given that it is apparently difficult to write a simple dg-directive
correctly, more is likely less... ;-) The dg-skip-if seems to be
very non-intuitive for the current purpose.
(And I did stumple over the two spaces in { dg-do run } myself before.)
Cheers,
Harald
Jakub
