Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines
Am 18.02.25 um 16:00 schrieb Andre Vehreschild: Hi Thomas, This patch series (of necessity) introduces ABI changes. What will happen with user code compiled against the old interface? That depends on the library you are linking against. When using caf_single from gfortran, then you will get link failures when you mix code compiled by gfortran < 15 and gfortran-15. But caf_single is anyhow only considered for testing. So why should one do this ? OK. If your questions targets the users of this ABI, which to my knowledge is only OpenCoarrays at the moment, then the user will experience nothing. A mix of pre-gfortran-15 and gfortran-15 generated .o-files will link and work as expected, because OpenCoarrays provides all ABIs. We do not compile a gfortran-15 exclusive version of OpenCoarrays, i.e. all routines are present, fully functional and interoperable. Very good, then. I guess a link failure (plus an answer in stack exchange where the explanation is given, so people can google it, and a mention in the release notes) would be acceptable, but is there anything that can be done in addition? I can provide an entry in release notes, if need be. Where do I have to do this? Never did. It is a separate repository from the gcc source, it can be found by cloning git+ssh://you...@gcc.gnu.org/git/gcc-wwwdocs.git . Best regards (and a lot of thanks for the patch series!) Thomas
DLL with gfortran open statement crashes Excel
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
[committed] gfortran.dg/gomp/metadirective-3.f90
With a compiler setup to compile (also) for nvptx offloading,
the testcase triggered a bogus error - and that prevents in
addition the gimple scan.
Fixed by adding an xfail and an xfailed dg-bogus.
The issue itself is the known https://gcc.gnu.org/PR118694
Committed as obvious asr15-7606-g8d922a80396b0c, cf. attachment. Tobias
commit 8d922a80396b0cc9f5311d79aa760412dd018848
Author: Tobias Burnus
Date: Tue Feb 18 15:48:39 2025 +0100
gfortran.dg/gomp/metadirective-3.f90: xfail on offload_nvptx
Currently, 'target' with a nested metadirective creating a 'teams' will
fail with a bogus error ("‘target’ construct with nested ‘teams’ construct
contains directives outside of the ‘teams’ construct").
That's tracked at PR118694 - and, hence, expected.
However, the testcase metadirective-3.f90 triggers this when compiling for
'target offload_nvptx' (otherwise, the code is optimized away). Use xfail to
silence the error as it is known and there is a tracking PR.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/metadirective-3.f90: Add xfail when
compiling for offload_nvptx.
---
gcc/testsuite/gfortran.dg/gomp/metadirective-3.f90 | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gfortran.dg/gomp/metadirective-3.f90 b/gcc/testsuite/gfortran.dg/gomp/metadirective-3.f90
index c5e25e598eb..e2ebb0a39c1 100644
--- a/gcc/testsuite/gfortran.dg/gomp/metadirective-3.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/metadirective-3.f90
@@ -22,4 +22,7 @@ end module
! that alternative and not produce a metadirective at all. Otherwise this
! won't be resolved until late.
! { dg-final { scan-tree-dump-not "#pragma omp metadirective" "gimple" { target { ! offload_nvptx } } } }
-! { dg-final { scan-tree-dump "#pragma omp metadirective" "gimple" { target { offload_nvptx } } } }
+
+! The following two are xfail because the bogus error triggers and thus prevents the dump, cf. PR118694
+! { dg-final { scan-tree-dump "#pragma omp metadirective" "gimple" { target { offload_nvptx } xfail { offload_nvptx } } } }
+! { dg-bogus "'target' construct with nested 'teams' construct contains directives outside of the 'teams' construct" "PR118694" { xfail offload_nvptx } 10 }
Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines
Hi Jerry, thank you very much for taking on the job of reviewing and sorry for my late answer. In fact, I was having a hard time figuring regressions in the OpenCoarrays library. This also answers your first question: Yes, OpenCoarrays will make use of the new interface. Most of the changes in the interface are required by OpenCoarrays. Today I got all OpenCoarray's tests passing. The OpenCoarrays tests all run a little bit faster than with the old method. Please keep in mind, that those tests keep starting and stopping tiny apps. I.e. the overhead of this sequential part is significant. Unfortunately the speedup is tiny (about 3 seconds for the whole suite running now in 1:21.38 (m:ss.ms; Release-build, i.e. -O3; mpich and Intel's mpi). I will look for a better benchmark suite. I think to remember that in some ticket on OpenCoarrays one was mentioned. Nevertheless are all these tests run on single machine. I have no cluster to command. I will rebase, rename rewrite.cc to coarray.cc, retest and merge shortly, if no one objects. Then I unfortunately have to post a new small bugfix (about 10 lines). Thanks again, Andre On Fri, 14 Feb 2025 10:19:28 -0800 Jerry D wrote: > On 2/13/25 11:48 AM, Jerry D wrote: > > On 2/10/25 2:25 AM, Andre Vehreschild wrote: > >> [PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635] > >> > > > > I have applied all patches. Regression tested OK here. > > > > From patch 5 there was one reject: > > > > patching file gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90 > > Hunk #1 FAILED at 39. > > 1 out of 1 hunk FAILED -- saving rejects to file gcc/testsuite/ > > gfortran.dg/coarray/send_char_array_1.f90.rej > > > > > I commented earlier about changing the name of rewrite.cc. > this please. > > > > I am now going through the whole enchilada for editorial stuff. > > > > Regards, > > > > I finished going through the last nine yards and it looks good. I have a > couple of questions: > > Have you been able to test against the OpenCoarray tests? > > Have you been able to measure any performance improvements? > > I suspect that the latter question may relate only to multi-node large > systems. > > I think this is good to commit. (all 7 parts) > > Does anyone else have any comments? > > Regards, > > Jerry > > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines
Hi Thomas, > This patch series (of necessity) introduces ABI changes. What will > happen with user code compiled against the old interface? That depends on the library you are linking against. When using caf_single from gfortran, then you will get link failures when you mix code compiled by gfortran < 15 and gfortran-15. But caf_single is anyhow only considered for testing. So why should one do this ? If your questions targets the users of this ABI, which to my knowledge is only OpenCoarrays at the moment, then the user will experience nothing. A mix of pre-gfortran-15 and gfortran-15 generated .o-files will link and work as expected, because OpenCoarrays provides all ABIs. We do not compile a gfortran-15 exclusive version of OpenCoarrays, i.e. all routines are present, fully functional and interoperable. > I guess a link failure (plus an answer in stack exchange where the > explanation is given, so people can google it, and a mention in the > release notes) would be acceptable, but is there anything that > can be done in addition? I can provide an entry in release notes, if need be. Where do I have to do this? Never did. Thanks again, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
