Re: [Fortran, Patch, PR107635, 4_v2] Fix class type and descriptor handling for new coarray interface [PR107635]
Hi Harald, thanks for the review. Committed this and the other patch as gcc-15-7694-gaf73228fdb2. Thanks again, Andre On Mon, 24 Feb 2025 20:22:17 +0100 Harald Anlauf wrote: > Hi Andre, > > Am 24.02.25 um 16:44 schrieb Andre Vehreschild: > > Hi Harald, > > > > I have added some comment(s). Can you take another look? > > assuming that you refer to the attachment of the other submission: > that one is perfect! > > This one is also OK. > > Thanks for the patch(es)! > > Harald > > > Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline? > > > > Regards, > > Andre > > > > On Sat, 22 Feb 2025 17:36:55 +0100 > > Andre Vehreschild wrote: > > > >> Hi Harald, > >> > >> thanks for the review. Silently I'd hoped that there is some macro to get > >> the i-th argument, that I just haven't found and someone could point me to. > >> I will add a comment, when ko one comes up with the macro by Monday. > >> > >> Thanks, > >> Andre > >> Andre Vehreschild * ve...@gmx.de > >> Am 22. Februar 2025 15:29:20 schrieb Harald Anlauf : > >> > >>> Hi Andre, > >>> > >>> Am 21.02.25 um 14:35 schrieb Andre Vehreschild: > Hi all, > > during testing and compiling some larger coarray codes, I found a few > deficiencies. One was with handling class types when splitting the > coarray expression and the other was that the backend_decl of a formal > argument in a function's symbol was not the same as the one the function > was compiled to. So looking at the function-decl's tree n-th formal > argument is the way to go there. > > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? > >>> > >>> I am amazed that you do not get lost handling 9-fold nested > >>> macros! This is OK, as this touches your CAF code. > >>> > >>> Otherwise, I'd recommend to add an explaining comment in the > >>> code or code such that mere mortals have a better chance to > >>> follow... > >>> > >>> Thanks, > >>> Harald > >>> > Regards, > Andre > -- > Andre Vehreschild * Email: vehre ad gmx dot de > >> > > > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > -- Andre Vehreschild * Email: vehre ad gmx dot de
[PATCH 0/4] Fortran: Improve flow of intrinsics/library documentation [PR47928]
This series addresses PR 47928, a Fortran documentation issue filed back in 2011. Quoting from the issue: "IMHO the order of paragraphs in the intrinsics chapter of the manual is a bit illogical. For instance, the description comes before the (strangely named) syntax paragraph, so when the description refers to arguments it's a bit backwards. Similarly, is the version of the standard where the intrinsic was introduced really the second most important thing a user needs to know?" I'd also thought that the ordering of the syntax/description subheadings was confusing even before I found this issue, so I figured this was a worthwhile documentation fix for me to tackle. Only the first part involved manual editing; the other three patches were purely mechanical: search-and-replace for part 2, Emacs keyboard macros for parts 3 and 4 (it did take me a few attempts before I got the latter right). I did confirm that part 2 consisted of nothing but whitespace changes and that parts 3 and 4 did not add or lose any lines, only change their ordering. I skimmed both the patches and the final PDF output but I admit I didn't do a line-by-line review of the entire patch series. Both parts 3 and 4 are too big for the mailing list so I have attached the whole set as a tarball instead of posting the pieces individually. I'll hold off on pushing this patch series for a few days in case anybody else does want to review it. I can see that the documentation for the intrinsics and library functions still needs a lot of cleanup in addition to this patch. There are problems all over the place with inconsistent use of @var markup to describe arguments, some instances of missing @code markup on symbolic constants, poor formatting of the syntax/synopsis in the library function documentation with line breaks in random places, places where using a table for formatting would greatly improve readability (e.g. _gfortran_set_options), etc. But those are separate from the issue addressed by this patch series and would need to be addressed individually by hand. -Sandra Sandra Loosemore (4): Fortran: Tidy subheadings in Fortran documentation [PR47928] Fortran: Whitespace cleanup in documentation [PR47928] Fortran: Rename/move "Syntax" subheading in documentation [PR47928] Fortran: Move "Standard" subheading in documentation [PR47928] gcc/fortran/gfortran.texi | 387 ++-- gcc/fortran/intrinsic.texi | 3912 ++-- 2 files changed, 2147 insertions(+), 2152 deletions(-) -- 2.34.1 pr47928.tgz Description: application/compressed-tar
[Fortran, Patch, PR108233, v1] Prevent SAVE_EXPR on lhs in assign.
Hi all,
for some recreation after all the coarray stuff, I found this pr cc'ed to me.
Taking a look at it, I figured that using a SAVE_EXPR on the lhs of the
assignment was doing the harm. The data seems to be not written back into the
vector shaped data type (like a complex number in this case). The current fix
just removes the save_expr from the lhs in an assignment and everything is fine.
Regtest ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 9307720090584a324b24b32e187a2da43ceaf969 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Tue, 25 Feb 2025 14:17:16 +0100
Subject: [PATCH] Fortran: Remove SAVE_EXPR on lhs in assign [PR108233]
With vectorial shaped datatypes like e.g. complex numbers, fold_convert
inserts a SAVE_EXPR. Using that on the lhs in an assignment prevented
the update of the variable, when in a coarray.
PR fortran/108233
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_trans_assignment_1): Remove SAVE_EXPR on lhs.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/complex_1.f90: New test.
---
gcc/fortran/trans-expr.cc | 13 +---
.../gfortran.dg/coarray/complex_1.f90 | 31 +++
2 files changed, 39 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/coarray/complex_1.f90
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 8a3e737a6a8..ab55940638e 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -13017,11 +13017,14 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
else
{
gfc_conv_expr (&lse, expr1);
- if (gfc_option.rtcheck & GFC_RTCHECK_MEM
- && !init_flag
- && gfc_expr_attr (expr1).allocatable
- && expr1->rank
- && !expr2->rank)
+ /* For some expression (e.g. complex numbers) fold_convert uses a
+ SAVE_EXPR, which is hazardous on the lhs, because the value is
+ not updated when assigned to. */
+ if (TREE_CODE (lse.expr) == SAVE_EXPR)
+ lse.expr = TREE_OPERAND (lse.expr, 0);
+
+ if (gfc_option.rtcheck & GFC_RTCHECK_MEM && !init_flag
+ && gfc_expr_attr (expr1).allocatable && expr1->rank && !expr2->rank)
{
tree cond;
const char* msg;
diff --git a/gcc/testsuite/gfortran.dg/coarray/complex_1.f90 b/gcc/testsuite/gfortran.dg/coarray/complex_1.f90
new file mode 100644
index 000..5db0b795278
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/complex_1.f90
@@ -0,0 +1,31 @@
+!{ dg-do run }
+
+! Check that complex numbers in coarrays can get assigned to.
+! Contributed by Harald Anlauf
+
+program pr108233
+ implicit none
+ complex :: c = (3.0,4.0), z[*] = (6.0, 7.0)
+ complex, allocatable :: y[:]
+ allocate (y[*])
+ y = c ! allocatable complex scalar coarray is OK
+ if (c /= y) error stop 1
+ z = c ! non-allocatable complex scalar coarray was bad
+ if (c /= z) error stop 2
+ call bcast_scalar (z, c) ! failed too
+ if (c /= z) error stop 3
+ call assign_scalar (z, c) ! this works
+ if (c /= z) error stop 4
+contains
+ subroutine assign_scalar (out, in)
+complex, intent(out) :: out
+complex, intent(in) :: in
+out = in
+ end subroutine assign_scalar
+ subroutine bcast_scalar (out, in)
+complex, intent(out) :: out[*]
+complex, intent(in) :: in
+out = in
+ end subroutine bcast_scalar
+end
+
--
2.48.1
Re: [Fortran, Patch, PR108233, v1] Prevent SAVE_EXPR on lhs in assign.
On 2/25/25 9:18 AM, Andre Vehreschild wrote: Hi all, for some recreation after all the coarray stuff, I found this pr cc'ed to me. Taking a look at it, I figured that using a SAVE_EXPR on the lhs of the assignment was doing the harm. The data seems to be not written back into the vector shaped data type (like a complex number in this case). The current fix just removes the save_expr from the lhs in an assignment and everything is fine. Regtest ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Looks OK Andre, thanks. Jerry Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: DLL with gfortran open statement crashes Excel
In the meantime I found out what is causing the problem. There seems to
be a bug in the connection from gfortran to UCRT (Microsofts universal C
runtime, that ships with Windows 10 and 11). If I switch to a compiler
that uses MSVCRT (Microsoft Visual C runtime, an older library, but
still available) the problem disappears.
The port of the mingw64 I use comes in both flavors. So using the MSVCRT
version solves it.
Juergen
Am 18.02.25 um 13:56 schrieb Jürgen Bausa:
I am trying to compile some C and fortran code inserted into a dll to be
called by Excel. However, on each successful Fortran open statment Excel
crashes without any message. Everything else works perfectly so I am
sure the Excel/DLL interface works in principle.
I also found out, that the crash only happens if the open (for reading,
STATUS='OLD') statment is successful. So if I delete the file to open,
the program runs fine.
I then tried to call the same routine in the dll from a C program. That
works fine in both cases (file to open exists or does not exist).
As the problem arose in a very big project I tried to write a very
simple version that results in the same problem (see below).
At the moment I think the problem is most likely caused by libgfortrans
implementation of open. It seems to be somehow incompatible with Excel.
Is there a way to debug this? I was thinking about compiling my own
ligfortran and add some debug code to find out, where exactly the
problem is. Any other suggestions?
I am using Windows 11 and Excel 365 (both 64 Bit) and GCC 14.2.0 WIN64
from winlibs (https://winlibs.com/).
Here is my example:
f77open.f ---
SUBROUTINE F77OPEN(STATUS)
INTEGER STATUS
STATUS=0
OPEN (UNIT=10, FILE='C:\Users\ztbau\btx.dat',
2 ERR=100, IOSTAT=IOERR, STATUS='OLD')
CLOSE(10)
RETURN
100 STATUS=2
RETURN
END
-
f77open.h ---
#include
#ifdef __cplusplus
#include
#define __GFORTRAN_FLOAT_COMPLEX std::complex
#define __GFORTRAN_DOUBLE_COMPLEX std::complex
#define __GFORTRAN_LONG_DOUBLE_COMPLEX std::complex
extern "C" {
#else
#define __GFORTRAN_FLOAT_COMPLEX float _Complex
#define __GFORTRAN_DOUBLE_COMPLEX double _Complex
#define __GFORTRAN_LONG_DOUBLE_COMPLEX long double _Complex
#endif
/* Prototypes for external procedures generated from f77open.f
by GNU Fortran (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht
Sanders, r3) 14.2.0.
Use of this interface is discouraged, consider using the
BIND(C) feature of standard Fortran instead. */
void f77open_ (int *status);
#ifdef __cplusplus
}
#endif
---
dlltest2.c
#include
#include
#include
#include
#include
#include "f77open.h"
int WINAPI dlltest2()
{
int status=0;
f77open_ (&status);
return status;
}
to compile I use the following commands:
gcc -march=native -fno-diagnostics-color -Wall -c -o dlltest2.o dlltest2.c
gfortran -march=native -fno-diagnostics-color -Wall -c f77open.f
gcc -march=native -fno-diagnostics-color -shared -Wl,--add-stdcall-alias
dlltest2.o f77open.o -o dlltest2.dll -lgfortran
Regards,
Juergen
Re: DLL with gfortran open statement crashes Excel
On 2/25/25 11:41 AM, Jürgen Bausa wrote:
In the meantime I found out what is causing the problem. There seems to
be a bug in the connection from gfortran to UCRT (Microsofts universal C
runtime, that ships with Windows 10 and 11). If I switch to a compiler
that uses MSVCRT (Microsoft Visual C runtime, an older library, but
still available) the problem disappears.
The port of the mingw64 I use comes in both flavors. So using the MSVCRT
version solves it.
Juergen
Am 18.02.25 um 13:56 schrieb Jürgen Bausa:
I am trying to compile some C and fortran code inserted into a dll to be
called by Excel. However, on each successful Fortran open statment Excel
crashes without any message. Everything else works perfectly so I am
sure the Excel/DLL interface works in principle.
I also found out, that the crash only happens if the open (for reading,
STATUS='OLD') statment is successful. So if I delete the file to open,
the program runs fine.
I then tried to call the same routine in the dll from a C program. That
works fine in both cases (file to open exists or does not exist).
As the problem arose in a very big project I tried to write a very
simple version that results in the same problem (see below).
At the moment I think the problem is most likely caused by libgfortrans
implementation of open. It seems to be somehow incompatible with Excel.
Is there a way to debug this? I was thinking about compiling my own
ligfortran and add some debug code to find out, where exactly the
problem is. Any other suggestions?
I am using Windows 11 and Excel 365 (both 64 Bit) and GCC 14.2.0 WIN64
from winlibs (https://winlibs.com/).
Here is my example:
f77open.f ---
SUBROUTINE F77OPEN(STATUS)
INTEGER STATUS
STATUS=0
OPEN (UNIT=10, FILE='C:\Users\ztbau\btx.dat',
2 ERR=100, IOSTAT=IOERR, STATUS='OLD')
CLOSE(10)
RETURN
100 STATUS=2
RETURN
END
-
f77open.h ---
#include
#ifdef __cplusplus
#include
#define __GFORTRAN_FLOAT_COMPLEX std::complex
#define __GFORTRAN_DOUBLE_COMPLEX std::complex
#define __GFORTRAN_LONG_DOUBLE_COMPLEX std::complex
extern "C" {
#else
#define __GFORTRAN_FLOAT_COMPLEX float _Complex
#define __GFORTRAN_DOUBLE_COMPLEX double _Complex
#define __GFORTRAN_LONG_DOUBLE_COMPLEX long double _Complex
#endif
/* Prototypes for external procedures generated from f77open.f
by GNU Fortran (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht
Sanders, r3) 14.2.0.
Use of this interface is discouraged, consider using the
BIND(C) feature of standard Fortran instead. */
void f77open_ (int *status);
#ifdef __cplusplus
}
#endif
---
dlltest2.c
#include
#include
#include
#include
#include
#include "f77open.h"
int WINAPI dlltest2()
{
int status=0;
f77open_ (&status);
return status;
}
to compile I use the following commands:
gcc -march=native -fno-diagnostics-color -Wall -c -o dlltest2.o
dlltest2.c
gfortran -march=native -fno-diagnostics-color -Wall -c f77open.f
gcc -march=native -fno-diagnostics-color -shared -Wl,--add-stdcall-alias
dlltest2.o f77open.o -o dlltest2.dll -lgfortran
Regards,
Juergen
Thanks for the info. Having worked in an all Windows environment for
several years, MS has a tendency toward not maintaining backward
compatibility. This is not unique to MS but a fairly common issue across
many software environments.
Jerry
