Fortran: Use non conflicting file extensions for intermediates [PR81615]
Dear all,
In the spirit of c/c++ using the .i/.ii extensions for intermediates,
use the .fi/.fii intermediate extensions for gfortran fixed/free form
sources when -save-temps is invoked to avoid various issues.
The documentation part will be submitted separately, because it
involves adding a "Developer options" mini-section (as suggested by
Harald) and moving the -fdump-* options from "Options for debugging
your program or GNU Fortran" section.
Regards,
Rimvydas
From d313ccb110c5418260b667c5f289a249247de059 Mon Sep 17 00:00:00 2001
From: Rimvydas Jasinskas
Date: Wed, 20 Dec 2023 03:39:33 +
Subject: Fortran: Use non conflicting file extensions for intermediates
[PR81615]
gcc/ChangeLog:
* doc/invoke.texi: Document the new file extensions
gcc/fortran/ChangeLog:
PR fortran/81615
* lang-specs.h (F951_CPP_OPTIONS): Do not hardcode ".f90" extension
(F951_CPP_EXTENSION): Use .fi/.fii for fixed/free form sources
* options.cc (form_from_filename): Handle the new extensions
Signed-off-by: Rimvydas Jasinskas
---
gcc/doc/invoke.texi | 2 ++
gcc/fortran/lang-specs.h | 10 +-
gcc/fortran/options.cc | 6 ++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 940adbce1bd..22313a86d9a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1591,6 +1591,7 @@ C++ header file to be turned into a precompiled header or Ada spec.
@item @var{file}.f
@itemx @var{file}.for
@itemx @var{file}.ftn
+@itemx @var{file}.fi
Fixed form Fortran source code that should not be preprocessed.
@item @var{file}.F
@@ -1605,6 +1606,7 @@ preprocessor).
@itemx @var{file}.f95
@itemx @var{file}.f03
@itemx @var{file}.f08
+@itemx @var{file}.fii
Free form Fortran source code that should not be preprocessed.
@item @var{file}.F90
diff --git a/gcc/fortran/lang-specs.h b/gcc/fortran/lang-specs.h
index 7b298457613..5b1ea00cf0d 100644
--- a/gcc/fortran/lang-specs.h
+++ b/gcc/fortran/lang-specs.h
@@ -29,7 +29,8 @@
/* Options that f951 should know about, even if not preprocessing. */
#define CPP_FORWARD_OPTIONS "%{i*} %{I*} %{M*}"
-#define F951_CPP_OPTIONS"%{!nocpp: -cpp=%g.f90 %{E} %(cpp_unique_options) \
+#define F951_CPP_OPTIONS"%{!nocpp: -cpp=%g" F951_CPP_EXTENSION \
+ " %{E} %(cpp_unique_options) \
%{E|M|MM:%(cpp_debug_options) " CPP_ONLY_OPTIONS \
" -fsyntax-only};: " CPP_FORWARD_OPTIONS "}"
@@ -44,6 +45,7 @@
#define F951_SOURCE_FORM"%{!ffree-form:-ffixed-form}"
+#define F951_CPP_EXTENSION ".fi"
{".F", "@f77-cpp-input", 0, 0, 0},
{".FOR", "@f77-cpp-input", 0, 0, 0},
{".FTN", "@f77-cpp-input", 0, 0, 0},
@@ -55,11 +57,15 @@
{".f", "@f77", 0, 0, 0},
{".for", "@f77", 0, 0, 0},
{".ftn", "@f77", 0, 0, 0},
+{".fi", "@f77", 0, 0, 0},
{"@f77",
"f951 %i " F951_SOURCE_FORM " \
%{E:%{!cpp:%egfortran does not support -E without -cpp}} \
%{cpp:" F951_CPP_OPTIONS ";: " CPP_FORWARD_OPTIONS "} \
%{!E:" F951_OPTIONS "}", 0, 0, 0},
+
+#undef F951_CPP_EXTENSION
+#define F951_CPP_EXTENSION ".fii"
{".F90", "@f95-cpp-input", 0, 0, 0},
{".F95", "@f95-cpp-input", 0, 0, 0},
{".F03", "@f95-cpp-input", 0, 0, 0},
@@ -70,6 +76,7 @@
{".f95", "@f95", 0, 0, 0},
{".f03", "@f95", 0, 0, 0},
{".f08", "@f95", 0, 0, 0},
+{".fii", "@f95", 0, 0, 0},
{"@f95",
"f951 %i %{E:%{!cpp:%egfortran does not support -E without -cpp}}\
%{cpp:" F951_CPP_OPTIONS ";: " CPP_FORWARD_OPTIONS "} \
@@ -79,5 +86,6 @@
#undef CPP_ONLY_OPTIONS
#undef CPP_FORWARD_OPTIONS
#undef F951_SOURCE_FORM
+#undef F951_CPP_EXTENSION
#undef F951_CPP_OPTIONS
#undef F951_OPTIONS
diff --git a/gcc/fortran/options.cc b/gcc/fortran/options.cc
index 02a29f83b58..53a6e8553bb 100644
--- a/gcc/fortran/options.cc
+++ b/gcc/fortran/options.cc
@@ -199,6 +199,12 @@ form_from_filename (const char *filename)
".f08", FORM_FREE}
,
{
+".fii", FORM_FREE}
+,
+{
+".fi", FORM_FIXED}
+,
+{
".f", FORM_FIXED}
,
{
--
2.43.0
Re: libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted
> Likely GFC_INTEGER_8 or int64_t or compatible. We have 32/64bit and > -fdefault-integer-8 to deal with… That’s why I am suggesting either “int” or “size_t”, i.e., a well-defined C type. Means we don’t have to deal with -fdefault-integer. FX
Aw: Re: libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted
Hi Steve, > At one time, we kept track of things that would break > libgfortran's ABI on the wiki. You can find the list > at https://gcc.gnu.org/wiki/LibgfortranAbiCleanup. > This could be old and moldy as I haven't checked in > on ABI changes in a long time. this looks indeed old and moldy... > > If we do not want to break the existing ABI, so that we can > > link gfortran-13 and gfortran-14+(?) compiled code, we need > > to keep _gfortran_get_command_i4 & friends, and introduce > > new library functions that are able to handle the new > > requirements. > > > > Do we have recommendations for a naming scheme? > > Like _gfortran_F2018_get_command_i4 > > or _gfortran_get_command_F2018_i4, or better? > > The only convention that I can recall is the > _gfortran_ prefix and the kind type suffix _i4. OK. > > And would that be fine, given that 14-development is in stage-3? > > Or rather wait for the next stage-1? > > In the past gfortran developers have had some leeway in > making this type of change in stage-3, because the change > would only affect gfortran (unless you somehow manage to > break bootstrap). There's always this tiny chance to overlook something ... > For these changes, I think we need create new symbols. > I'm not a fan of encoding F2018 into the name as the 'new' > optional arguments are present in F2023. Perhaps, a simple > version number _gfortran_get_command_v1_i4. I also thought about the version number, but wasn't really happy with it. The new interface would exist for F2018+. I am not aware that any intrinsic ever lost an argument, and dealing with that would be trivial. The intrinsics mentioned are special in the sense that they have a common additional optional argument ERRMSG, and they are all impure subroutines. This allows for another solution: keeping the ERRMSG as a kind of "iostat" in the library, and if this argument is present in the call, one can inquire libgfortran to return that ERRMSG. This would even be backward-compatible. :-) The biggest issue I see is that this library variable would need to be thread-local. I have to figure that out yet... Harald
Aw: Re: libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted
Hi FX, > Hi Harald, > > > If we do not want to break the existing ABI, so that we can > > link gfortran-13 and gfortran-14+(?) compiled code, we need > > to keep _gfortran_get_command_i4 & friends, and introduce > > new library functions that are able to handle the new > > requirements. > > I have been thinking about the large number of intrinsic implementations we > have, with their naming conventions (_i4, _i8, etc). The standard seems to go > in the direction of allowing more and more kind and type combinations (in > general), and our approach dooms us to an explosion of the library in terms > of number of functions. > > I believe this is in part because historically the front-end lowered most > intrinsics directly into a function call. But we don’t have to continue doing > that, and I would be in favour of limiting as much as we can the number of > library functions, and handle the rest in the front-end. yes, I agree. This is already successfully done in some cases (e.g. for system_clock). > For example, we could have one library-side function called > _gfortran_f2018_get_environment_variable with fixed integer types (probably > int or size_t). Then the conversions are handled in the front-end. Likely GFC_INTEGER_8 or int64_t or compatible. We have 32/64bit and -fdefault-integer-8 to deal with... Harald
Re: libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted
On Tue, Dec 19, 2023 at 09:07:08PM +0100, Harald Anlauf wrote: > Dear all, > > in Fortran 2018 a few intrinsics were extended and now support > additional optional arguments. See PR 85836 for the meta-bug, > and in particular: > > 96583 - get_environment_variable > 96584 - get_command > 96585 - get_command_argument > > with an optional ERRMSG. > > How are we going to deal with this? At one time, we kept track of things that would break libgfortran's ABI on the wiki. You can find the list at https://gcc.gnu.org/wiki/LibgfortranAbiCleanup. This could be old and moldy as I haven't checked in on ABI changes in a long time. > If we do not want to break the existing ABI, so that we can > link gfortran-13 and gfortran-14+(?) compiled code, we need > to keep _gfortran_get_command_i4 & friends, and introduce > new library functions that are able to handle the new > requirements. > > Do we have recommendations for a naming scheme? > Like _gfortran_F2018_get_command_i4 > or _gfortran_get_command_F2018_i4, or better? The only convention that I can recall is the _gfortran_ prefix and the kind type suffix _i4. > Would it be sufficient to update gfortran.map suitably? If you add a new symbol, then yes, gfortran.map would need to be updated to contain it. > Or do we need to bump something else? If you change the ABI of, say, get_command() you would need to bump the major version number for libgfortran. > And would that be fine, given that 14-development is in stage-3? > Or rather wait for the next stage-1? In the past gfortran developers have had some leeway in making this type of change in stage-3, because the change would only affect gfortran (unless you somehow manage to break bootstrap). For these changes, I think we need create new symbols. I'm not a fan of encoding F2018 into the name as the 'new' optional arguments are present in F2023. Perhaps, a simple version number _gfortran_get_command_v1_i4. -- Steve
Re: [PATCH] libgfortran: avoid duplicate libraries in spec
On 12/19/23 1:10 PM, FX Coudert wrote: Hi, I am getting side notes about people having these issues with gfortran 13. Is this something that should be backported. I have already backported it in the latest Homebrew package (because we have many users complaining about it). I intend to backport but will wait for a conservative amount of time before doing so. Apparently it is causing some none gfortran compilations to break, but I do not know if this is the same issue. Don’t think so. I can have a look if you give me a pointer. FX See: https://github.com/vmagnin/gtk-fortran/issues/280#issuecomment-1863377748 Thanks ahead of time if you have time. Jerry
Re: [PATCH] libgfortran: avoid duplicate libraries in spec
Hi, > I am getting side notes about people having these issues with gfortran 13. Is > this something that should be backported. I have already backported it in the latest Homebrew package (because we have many users complaining about it). I intend to backport but will wait for a conservative amount of time before doing so. > Apparently it is causing some none gfortran compilations to break, but I do > not know if this is the same issue. Don’t think so. I can have a look if you give me a pointer. FX
Re: libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted
Hi Harald, > If we do not want to break the existing ABI, so that we can > link gfortran-13 and gfortran-14+(?) compiled code, we need > to keep _gfortran_get_command_i4 & friends, and introduce > new library functions that are able to handle the new > requirements. I have been thinking about the large number of intrinsic implementations we have, with their naming conventions (_i4, _i8, etc). The standard seems to go in the direction of allowing more and more kind and type combinations (in general), and our approach dooms us to an explosion of the library in terms of number of functions. I believe this is in part because historically the front-end lowered most intrinsics directly into a function call. But we don’t have to continue doing that, and I would be in favour of limiting as much as we can the number of library functions, and handle the rest in the front-end. For example, we could have one library-side function called _gfortran_f2018_get_environment_variable with fixed integer types (probably int or size_t). Then the conversions are handled in the front-end. FX
Re: [PATCH] libgfortran: avoid duplicate libraries in spec
On 12/19/23 12:02 AM, FX Coudert wrote: When gfortran invokes the linker, it reads the linking spec from libgfortran. This ends up doing things like: -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This wasn’t a problem, until the new macOS linker, which gives a warning for this: the warning is innocuous, but having a warning for every time you call gfortran for linking clutters the terminal, and makes all the testsuite fail. And linking twice is superfluous, so removing it will not be a problem. I am the author of the original commit to the spec, in 2010, but honestly I have no memory: I think I vaguely remember saying “better safe than sorry”, but 13 years later it could just be a false memory ;) Anyway, this was tested on x86_64-darwin and x64_86-linux, as well as *-*-solaris2.11 by Rainer. OK to commit? (seems admissible in stage 3 because it fixes regtesting on darwin22 and darwin23). FX libgfortran/ChangeLog: PR libfortran/110651 * libgfortran.spec.in: Remove duplicate libraries. --- libgfortran/libgfortran.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) I am getting side notes about people having these issues with gfortran 13. Is this something that should be backported. Apparently it is causing some none gfortran compilations to break, but I do not know if this is the same issue. I say OK for trunk. Jerry
Re: [PATCH 1/5] OpenMP, NVPTX: memcpy[23]D bias correction
Hi Julian & Thomas, the patch LGTM - and seemingly also Thomas is somewhat fine with it - and it includes the stand-alone testcase. * * * I guess, you don't know the answer to Thomas question, i.e. whether that's a bug in CUDA or in our use of the CUDA API? CUDA's spec itself, https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__MEM.html has for cuMemcpy2D void* Start = (void*)((char*)srcHost+srcY*srcPitch + srcXInBytes); and for cuMemcpy3D void* Start = (void*)((char*)srcHost+(srcZ*srcHeight+srcY)*srcPitch + srcXInBytes); Thus, I assume we use it "properly", except that the CUDA writers probably assumed that one allocates a big chunk of memory and work with that memory and not just maps a subset. This might or might not be stated in the manual in the following: "Memory regions spanning over allocations that are both registered and not registered with CUDA are not supported and will return CUDA_ERROR_INVALID_VALUE." – where the question is whether everything until 'start' really counts as "spanning". Tobias On 02.10.23 16:53, Julian Brown wrote: On Wed, 27 Sep 2023 00:57:58 +0200 Thomas Schwinge wrote: On 2023-09-06T02:34:30-0700, Julian Brown wrote: This patch works around behaviour of the 2D and 3D memcpy operations in the CUDA driver runtime. Particularly in Fortran, the "base pointer" of an array (used for either source or destination of a host/device copy) may lie outside of data that is actually stored on the device. The fix is to make sure that we use the first element of data to be transferred instead, and adjust parameters accordingly. Do you (a) have a stand-alone test case for this (that is, not depending on your other pending patches, so that this could go in directly -- together with the before-FAIL test case). Thanks for the reply! Here's a version with a stand-alone test case. Do you (b) know if is this a bug in our use of the CUDA Driver API or rather in CUDA itself? If the latter, have you reported this to Nvidia? I don't think the CUDA behaviour is *wrong*, as such -- at least to the C/C++ way of thinking (or indeed a graphics-oriented way of thinking), one would normally think of an array as having a zero-based origin, and these 2D/3D memory copies would be intended as a way of updating just a part of an array (or texture) that has full duplicate copies on both the host and device. Our use-case just happens to be a bit different, both because Fortran (internally) represents an array by a zero-based origin but may use 1-based (or whatever-based) indices, and because we support partial mappings of host arrays on the device in all three supported languages -- which amounts to much the same thing, actually. That said, it *could* be fixed in CUDA, though probably not in all the versions currently deployed out there in the world. So I guess we'd still need a patch like this anyway. Julian - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted
Dear all, in Fortran 2018 a few intrinsics were extended and now support additional optional arguments. See PR 85836 for the meta-bug, and in particular: 96583 - get_environment_variable 96584 - get_command 96585 - get_command_argument with an optional ERRMSG. How are we going to deal with this? If we do not want to break the existing ABI, so that we can link gfortran-13 and gfortran-14+(?) compiled code, we need to keep _gfortran_get_command_i4 & friends, and introduce new library functions that are able to handle the new requirements. Do we have recommendations for a naming scheme? Like _gfortran_F2018_get_command_i4 or _gfortran_get_command_F2018_i4, or better? Would it be sufficient to update gfortran.map suitably? Or do we need to bump something else? And would that be fine, given that 14-development is in stage-3? Or rather wait for the next stage-1? Thanks, Harald
GFortran MatterMost Workspace
The subject server hosted by the OSU Open Software Lab is being upgraded to the latest LTS version of MatterMost (8.1). There may be some interruptions of service. I will send out a notice when this gets completed. Thanks to the folks at OSU for their support. Regards, Jerry
Re: [PATCH v7 5/5] OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc
Hi Julian,
On 16.12.23 14:25, Julian Brown wrote:
OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc
This patch has been separated out from the C++ "declare mapper"
support patch. It contains just the gimplify.cc rearrangement
work, mostly moving gimplification from gimplify_scan_omp_clauses
to gimplify_adjust_omp_clauses for map clauses.
The motivation for doing this was that we don't know if we need to
instantiate mappers implicitly until the body of an offload region has
been scanned, i.e. in gimplify_adjust_omp_clauses, but we also need the
un-gimplified form of clauses to sort by base-pointer dependencies after
mapper instantiation has taken place.
The patch also reimplements the "present" clause sorting code to avoid
another sorting pass on mapping nodes.
This version of the patch is based on the version posted for og13, and
additionally incorporates a follow-on fix for DECL_VALUE_EXPR handling
in gimplify_adjust_omp_clauses:
"OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc"
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/63.html
Parts of:
"OpenMP: OpenMP 5.2 semantics for pointers with unmapped target"
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623351.html
I find the patch hard to digest - and I wouldn't be surprised if I
missed something.
However, I think the patch is OK - except for a few minor observations:
2023-12-16 Julian Brown
gcc/
* gimplify.cc (omp_segregate_mapping_groups): Handle "present"
groups.
(gimplify_scan_omp_clauses): Use mapping group functionality to
iterate through mapping nodes. Remove most gimplification of
OMP_CLAUSE_MAP nodes from here, but still populate ctx->variables
splay tree.
(gimplify_adjust_omp_clauses): Move most gimplification of
OMP_CLAUSE_MAP nodes here.
gcc/testsuite/
* gfortran.dg/gomp/map-12.f90: Adjust scan output.
libgomp/
* testsuite/libgomp.fortran/target-enter-data-6.f90: Remove XFAIL.
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index a6bdceab45d..fa6ddd546f8 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -10107,6 +10114,20 @@ omp_segregate_mapping_groups (omp_mapping_group
*inlist)
ard_tail = >next;
break;
+ case GOMP_MAP_PRESENT_ALLOC:
+ *pa_tail = w;
+ w->next = NULL;
+ pa_tail = >next;
+ break;
+
+ case GOMP_MAP_PRESENT_FROM:
+ case GOMP_MAP_PRESENT_TO:
+ case GOMP_MAP_PRESENT_TOFROM:
+ *ptf_tail = w;
+ w->next = NULL;
+ ptf_tail = >next;
+ break;
+
First, I note that GOMP_MAP_PRESENT_ALLOC and
GOMP_MAP_PRESENT_{FROM,TO,TOFROM} are semantically identical: If the
variable is not present, error termination will happen - otherwise, if
present, no data movement will happen. Hence, they will be changed to
GOMP_MAP_FORCE_PRESENT in gimplify_adjust_omp_clauses.
That's also the reason that the old code handled all of them identical.
However, besides a plain 'present', there is also 'always' + 'present'.
Those are different as after a normal 'present' check (abort if not
present), the data copying will happen: GOMP_MAP_ALWAYS_PRESENT_TO,
GOMP_MAP_ALWAYS_PRESENT_FROM, GOMP_MAP_ALWAYS_PRESENT_TOFROM.
(Note that: always + present + alloc = GOMP_MAP_PRESENT_ALLOC (w/o
'always') as already done in the FE.)
Thus, all 'case' from your patch should go to a single group (possibly
adding a comment about it). The question is what to do with the
'present,always' case. I think leaving them under 'default:' is fine,
but I might have missed something.
default:
*tf_tail = w;
w->next = NULL;
@@ -10118,8 +10139,10 @@ omp_segregate_mapping_groups (omp_mapping_group
*inlist)
* * *
@@ -11922,119 +11945,30 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq
*pre_p,
break;
}
- if (code == OMP_TARGET
- || code == OMP_TARGET_DATA
- || code == OMP_TARGET_ENTER_DATA
- || code == OMP_TARGET_EXIT_DATA)
-{
- vec *groups;
- groups = omp_gather_mapping_groups (list_p);
- if (groups)
- {
- hash_map *grpmap;
- grpmap = omp_index_mapping_groups (groups);
+ vec *groups = omp_gather_mapping_groups (list_p);
+ hash_map *grpmap = NULL;
+ unsigned grpnum = 0;
+ tree *grp_start_p = NULL, grp_end = NULL_TREE;
...
- else if (region_type & ORT_ACC)
-{
I wonder whether you should not better call 'omp_gather_mapping_groups'
only for the 'code == OMP_TARGET...' and for ORT_ACC (or some subset of
OACC *), given that this function is also called
bygimplify_omp_parallel, gimplify_omp_task, gimplify_omp_for, ...
This avoids some memory allocation and list_p walking, i.e. it is not
too bad - but also not really needed for task, parallel, for, ...
@@ -14008,26 +13926,73 @@
[PATCH] libgfortran: avoid duplicate libraries in spec
When gfortran invokes the linker, it reads the linking spec from libgfortran. This ends up doing things like: -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This wasn’t a problem, until the new macOS linker, which gives a warning for this: the warning is innocuous, but having a warning for every time you call gfortran for linking clutters the terminal, and makes all the testsuite fail. And linking twice is superfluous, so removing it will not be a problem. I am the author of the original commit to the spec, in 2010, but honestly I have no memory: I think I vaguely remember saying “better safe than sorry”, but 13 years later it could just be a false memory ;) Anyway, this was tested on x86_64-darwin and x64_86-linux, as well as *-*-solaris2.11 by Rainer. OK to commit? (seems admissible in stage 3 because it fixes regtesting on darwin22 and darwin23). FX libgfortran/ChangeLog: PR libfortran/110651 * libgfortran.spec.in: Remove duplicate libraries. --- libgfortran/libgfortran.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 0001-libgfortran-avoid-duplicate-libraries-in-spec.patch Description: Binary data
