Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

[Thomas Koenig]

Am 21.03.25 um 15:34 schrieb Paul Richard Thomas:

I am reasonably familiar with the mess that is gfc_conv_procedure_call :-)


It's only 2141 lines in a single function and eight levels of
conditions / loops!

I do not see what could possibly go wrong :-)

Best regards

Thomas

[PATCH] testsuite: Replace the cray_pointers_2.f90 no cycling hack with dg-skip-if

[Jakub Jelinek]

On Thu, Mar 27, 2025 at 06:11:25PM +, Sam James wrote:
> >> diff --git a/gcc/testsuite/gfortran.dg/cray_pointers_2.f90 
> >> b/gcc/testsuite/gfortran.dg/cray_pointers_2.f90
> >> index 4351874825ed..a7e15bad850a 100644
> >> --- a/gcc/testsuite/gfortran.dg/cray_pointers_2.f90
> >> +++ b/gcc/testsuite/gfortran.dg/cray_pointers_2.f90
> >> @@ -1,6 +1,6 @@
> >>   ! Using two spaces between dg-do and run is a hack to keep 
> >> gfortran-dg-runtest
> >>   ! from cycling through optimization options for this expensive test.
> >> -! { dg-do  run }
> >> +! { dg-do run }
> >>   ! { dg-options "-O3 -fcray-pointer -fbounds-check -fno-inline" }
> >>   ! { dg-timeout-factor 4 }
> >>   !
> >
> > There was an attempt by Jerry some time ago to have a directive
> > for not cycling through options, but this is not yet available.
> 
> Ah, PR28032.

There already is a documented directive which can do that.

As documented, dg-skip-if allows to skip a test if some option appears in
the list (e.g. cycle through everything but skip the test with -O2) or skip
unless all the options from a string are included.

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.

Ok for trunk?

Or do you want the ! run_expensive_tests version?

2025-03-27  Jakub Jelinek  

* gfortran.dg/cray_pointers_2.f90: Replace { dg-do  run } hack with
dg-skip-if directive.

--- gcc/testsuite/gfortran.dg/cray_pointers_2.f90.jj2020-01-12 
11:54:38.207386342 +0100
+++ gcc/testsuite/gfortran.dg/cray_pointers_2.f90   2025-03-27 
19:23:29.237873386 +0100
@@ -1,6 +1,5 @@
-! Using two spaces between dg-do and run is a hack to keep gfortran-dg-runtest
-! from cycling through optimization options for this expensive test.
-! { dg-do  run }
+! { dg-do run }
+! { dg-skip-if "Don't cycle through options" { *-*-* }  { "*" } { "-O3 -g" } }
 ! { dg-options "-O3 -fcray-pointer -fbounds-check -fno-inline" }
 ! { dg-timeout-factor 4 }
 !


Jakub

GSoC[Fortran Runtime argument check ] Draft of Proposal and some doubts about the needs

[Gwen Fu]

My doubt :
1.Does the compilation option only need to support fortran versions above
9, o5r does it also need to support fortran 77?
2.Regarding parameter checking, *my idea is that after the user creates an
array of a specified size, it is passed into the function as a parameter*.
However, the array size required by the function does not match the size
specified by the user. However, this idea seems to be impossible to
implement in fortran77. *In addition, in addition to implicit and explicit
size arrays, are there other data structures that require parameter type
checking?*
3.
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 Is this related  to the project ?

Here is my proposal draft (importran part )
Parameter Mismatch Implicit Declaration Features of Fortran 77

I think this is the reason why parameter mismatch may occur

In *Fortran 77*, *Implicit Typing* is a variable type automatic inference
mechanism, that is, *the compiler automatically determines its data type
based on the first letter of the variable name* without explicit
declaration.
Variable first characterDefault data type
A-H O-Z AH OZ REAL (single-precision floating point number)
I-N INTEGER (integer)

*This will lead*

   -

   *Error-prone*: If you make a typo (e.g., TOTAL is mistakenly written as
   TOAL), the compiler will not report an error, but the variable type may
   change.
   -

   *Poor code readability*: Implicit rules are not intuitive, increasing
   maintenance difficulty.


Parameter mismatch of implicit-size or explicit-size array

*1. Assumed-size Array*

*Syntax example:*

SUBROUTINE SUB(A)
  DIMENSION A(*)  ! Assumed-size array
  INTEGER A
  ! ...
END

*Potential issues:*

   -

   *No bounds checking*: The compiler does not know the actual size of the
   array passed in, and relies entirely on the programmer to ensure correct
   access.
   -

   *Out-of-bounds risk*: If A(i) is accessed inside the function but i
   exceeds the actual array range, undefined behavior (such as memory
   corruption, program crash) will occur.
   -

   *No shape checking*: Even if the dimensions of the array passed in do
   not match (such as A(10) but the actual passed in A(5)), the compiler
   will not report an error.

*2. Explicit-size Array *

*Syntax example:*

SUBROUTINE SUB(A, N)
  DIMENSION A(N)  ! Explicit-size Array
  INTEGER A, N
  ! ...
END

*Potential Issues:*

   -

   *Manual Size Passing*: The array size N must be passed additionally,
   which is prone to errors (e.g. passing the wrong N).
   -

   *Mismatch Risk*: If N is larger than the actual array size, the function
   may access illegal memory.
   -

   *No Dimension Check*: The compiler will not warn even if the array
   dimensions passed in are different (e.g. A(10) vs A(5,2)).

Technology stack mastered

   -

   Familiar with C++/C language
   -

   Familiar with Linux environment programming, proficient in three IO
   multiplexing technologies: epoll, select, and poll, and their underlying
   principles
   -

   Proficient in debugging tools such as gdb valgrind
   -

   Understand Fortran language


Projects participated in

   -

   Personal project Lightweight HTTP server based on Reactor mode
   

This project is developed in C++, including log output module, connection
management module, business module, and I/O processing connection request
processing module

   -

   OSPP-2024 Kytunig-Client data output function module development
   

This project is developed in Python, and its core functions include
deserialization of JSON data and conversion of JSON data into Excel files.

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

[Paul Richard Thomas]

Hi Andre,

I am reasonably familiar with the mess that is gfc_conv_procedure_call :-)
So in spite of you having a hard time explaining things today, I see your
patch as verging on 'obvious' and is certainly the best that can be done
without refactoring the whole thing.

OK fo mainline.

Thanks for the patch

Paul


On Thu, 20 Mar 2025 at 16:36, Andre Vehreschild  wrote:

> Hi all,
>
> attached patch fixes a 15-regression where an element of an actual
> temporary array, i.e., elemental([ e1, e2...]) passed to the formal
> polymorphic
> dummy leads to a double free of the derived types components. This patch
> prevents this by preventing the deallocation of the array constructors
> temporary, when the formal is polymorphic. ...
>
> Folks its so hard to explain this in prose. I rewrote above paragraph the
> third
> time now. And I still don't understand on re-reading. So here is some
> pseudo
> code:
>
> struct derived {
>   char *c; // This is the component suffering from double-free
> };
>
> derived[2] atmp = [ derived(""), derived("")]
>
> forall a in atmp
>   derived t_a = a; // <- Copy of a, but no deep copy, i.e. t_a.c == a.c
>   class_temp = class_derived(a); // set _vtype left out for brevity
>   call elemental_function(class_temp);
>   if (class_temp._data.c != NULL)
> free(class_temp._data.c); // and set it to NULL
>   if (t_a.c != NULL)
> free(t_a.c); // BOOM, this is freeing the same c
> end
>
> Generating the last if-block and the free is what this patch prevents for
> polymorphic dummys that stem from an array construction. And only for
> those.
>
> Sorry, I am having a hard time explaining things today. So I hope the code
> above will do.
>
> Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>

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

[Steve Kargl]

On Thu, Mar 27, 2025 at 03:43:49PM +, 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

GSoC Draft Proposal Submission: Fortran 2018/202x

[Yuao Ma]

Hi GCC developers,

I'm sharing the draft proposal for my GSoC project titled "Fortran 2018/202x".
It has already been posted on the Fortran mailing list, where I received
valuable feedback from gfortran developers.

As mentioned on the GCC GSoC page, proposals should also be shared on the GCC
mailing list - so I’m submitting it here as well. I’d greatly appreciate any
feedback or suggestions to help refine the proposal further before the
submission deadline.

URL: https://drive.google.com/file/d/1cwj5gUxywgaqkcJWJM4Ps4IkbmAeWSAT

Thank you for your time and consideration!

Best regards,
Yuao

GSoC 2025 - Draft Proposal for Fortran 2018/202x - RFC

[Yuao Ma]

Dear gfortran developers,

I have uploaded a draft proposal for the 'Fortran – 2018/202x' project to the
platform. You can also find a PDF version at this Google Drive link:
https://drive.google.com/file/d/1cSRPuWpXWHMwHdNItQluEYspLfylqZcU.

Could you please review the proposal and provide feedback on how it can be
improved? Thank you for your time and advice.

Sincerely,
Yuao