Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope

2025-03-24 Thread Steve Kargl
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 f

Re: [Patch, Fortran] C prototypes for functions returning C function pointers

2025-03-24 Thread Harald Anlauf
Hi Thomas, Am 24.03.25 um 22:28 schrieb Thomas Koenig: Hi Harald, the attached patch contains a chunk changing resolve.cc that is neither described in the suggested commit message, and it fails to compile here: ../../gcc-trunk/gcc/fortran/resolve.cc: In function 'void check_c_funptr_assign_in

Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope

2025-03-24 Thread Janne Blomqvist
On Mon, Mar 24, 2025 at 8:25 PM Steve Kargl wrote: > > 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 i

Re: GSoC Fortran – 2018/202x – Inquiry About Project Scope

2025-03-24 Thread Steve Kargl
On Mon, Mar 24, 2025 at 08:46:50PM +0200, Janne Blomqvist wrote: > On Mon, Mar 24, 2025 at 8:25 PM Steve Kargl > wrote: > > > > 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

Re: [Patch, Fortran] C prototypes for functions returning C function pointers

2025-03-24 Thread Harald Anlauf
Hi Thomas, Am 24.03.25 um 21:40 schrieb Thomas Koenig: Hello world, the attached patch handles dumping prototypes for C functions returning function pointers.  For the test case MODULE test    USE, INTRINSIC :: ISO_C_BINDING CONTAINS    FUNCTION lookup(idx) BIND(C) type(C_FUNPTR) :: lo

Re: [Patch, Fortran] C prototypes for functions returning C function pointers

2025-03-24 Thread Steve Kargl
On Mon, Mar 24, 2025 at 09:40:38PM +0100, Thomas Koenig wrote: > > Regression-tested. Again no test case because I don't know > how. During testing, I also found that vtabs were dumped, > this is also corrected. > > OK for trunk? Thanks for working on this, but ... > > /* This section deals

GSoC Fortran – 2018/202x – Inquiry About Project Scope

2025-03-24 Thread Yuao Ma
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 document

[Patch, Fortran] C prototypes for functions returning C function pointers

2025-03-24 Thread Thomas Koenig
Hello world, the attached patch handles dumping prototypes for C functions returning function pointers. For the test case MODULE test USE, INTRINSIC :: ISO_C_BINDING CONTAINS FUNCTION lookup(idx) BIND(C) type(C_FUNPTR) :: lookup integer(C_INT), VALUE :: idx lookup = C_FUNLO

Re: [Patch, Fortran] C prototypes for functions returning C function pointers

2025-03-24 Thread Thomas Koenig
Hi Harald, the attached patch contains a chunk changing resolve.cc that is neither described in the suggested commit message, and it fails to compile here: ../../gcc-trunk/gcc/fortran/resolve.cc: In function 'void check_c_funptr_assign_interface(gfc_expr*, gfc_expr*)': ../../gcc-trunk/gcc/fortr

Re: Gsoc: Fortran-Do Concurrent

2025-03-24 Thread Martin Jambor
Hello, we are delighted you found contributing to GCC interesting. On Thu, Mar 13 2025, ahmad tariq via Gcc wrote: > Hi, > I'm Ahmad Abdul Rehman, a third year computer science undergraduate from > FAST(Pakistan). I am interested in the "Do-Concurrent" project, and I > noticed that some work has

Re: [COMMITTED] libgfortran/intrinsics: Fix build for targets with int32_t=long int

2025-03-24 Thread Steve Kargl
On Sun, Mar 23, 2025 at 10:09:46AM +0100, Thomas Koenig wrote: > Hi Paul, > > > By the way, the standard just specifies integer for 'dim' in reduce, > > which I take to mean it should be default_integer_kind. > > Hmm... I'm not sure that this is actually the case; I believe it > can actually be a