Re: [PATCH] Fortran: set shape of initializers of zero-sized arrays [PR95374,PR104352]
On 5/17/23 11:52 AM, Harald Anlauf via Fortran wrote: Dear all, the attached patch is neat, because it fixes a bug by removing code ;-) When generating the initializer for a parameter array, we excepted the case of size 0, which however prevented the detection of array bounds violations and lead to ICEs in various places. The solution which removes the comparison for size > 0 also has the bonus that it fixes a minor memory leak for the size==0 case... Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Looks Good To Me. OK, Jerry
Re: Building Legacy Code and Intel Libraries
On Wed, May 17, 2023 at 1:15 PM Larry Lemons via Fortran wrote: > > Hello, > > I inherited a project where the customer wants us to re-build this ForTran > application with a more modern compiler. I did some research and found that > the GCC compiler probably has the most up to date compiler available, so we > decided to us 13.1.0 version of GCC. It has been about 40 years since I last > used Fortran, and very little at that time, and I didn't realize that there > were different libraries available based upon which compiler that was used at > the time. Apparently, from what I can tell from the research that I've done, > is it was last built using a MicroSoft compiler because of two of the > libraries that are used. From what I've read, Compaq had the compiler for a > time and now Intel has it. > > Anyway, since I was not the person who originally worked on this code, I am > not sure what functionality from the two libraries are being used, so I would > like to find the one or more libraries that are equivalent to the libraries > that are being used from the Intel libraries. From what I understand, the > libraries have been split up into more than one library since Intel took it > over, but all that I know is that the two libraries in question are DFPORT > and DFLIB. > > Can someone help me find the equivalent libraries in GCC that replace all of > the functionality in DFPORT and DFLIB or point me in a direction where I can > find this information? I've been trying to find it for the last 3 weeks and > have found a lot of things, but nothing I can use or that works. I've tried, > unsuccessfully, to use the Intel libraries, as well as trying to rebuild > them. If there aren't any equivalent libraries then I may need to work on > getting the Intel compiler added to the software list, which will take > another month or more. Please read https://gcc.gnu.org/legacy-ml/fortran/2010-04/msg00314.html for about DFPORT and gfortran. For DFLIB, you might need to re-implement some of it. It looks like it was Windows only even. Thanks, Andrew Pinski > > So any help would be very much appreciated. > > Thank you, > > Larry M. Lemons > Sr. Software Developer
Building Legacy Code and Intel Libraries
Hello, I inherited a project where the customer wants us to re-build this ForTran application with a more modern compiler. I did some research and found that the GCC compiler probably has the most up to date compiler available, so we decided to us 13.1.0 version of GCC. It has been about 40 years since I last used Fortran, and very little at that time, and I didn't realize that there were different libraries available based upon which compiler that was used at the time. Apparently, from what I can tell from the research that I've done, is it was last built using a MicroSoft compiler because of two of the libraries that are used. From what I've read, Compaq had the compiler for a time and now Intel has it. Anyway, since I was not the person who originally worked on this code, I am not sure what functionality from the two libraries are being used, so I would like to find the one or more libraries that are equivalent to the libraries that are being used from the Intel libraries. From what I understand, the libraries have been split up into more than one library since Intel took it over, but all that I know is that the two libraries in question are DFPORT and DFLIB. Can someone help me find the equivalent libraries in GCC that replace all of the functionality in DFPORT and DFLIB or point me in a direction where I can find this information? I've been trying to find it for the last 3 weeks and have found a lot of things, but nothing I can use or that works. I've tried, unsuccessfully, to use the Intel libraries, as well as trying to rebuild them. If there aren't any equivalent libraries then I may need to work on getting the Intel compiler added to the software list, which will take another month or more. So any help would be very much appreciated. Thank you, Larry M. Lemons Sr. Software Developer
Re: [PATCH] Fortran: set shape of initializers of zero-sized arrays [PR95374,PR104352]
Le 17/05/2023 à 20:52, Harald Anlauf via Fortran a écrit : Dear all, the attached patch is neat, because it fixes a bug by removing code ;-) When generating the initializer for a parameter array, we excepted the case of size 0, which however prevented the detection of array bounds violations and lead to ICEs in various places. The solution which removes the comparison for size > 0 also has the bonus that it fixes a minor memory leak for the size==0 case... Regtested on x86_64-pc-linux-gnu. OK for mainline? Sure. Thanks
[PATCH] Fortran: set shape of initializers of zero-sized arrays [PR95374,PR104352]
Dear all,
the attached patch is neat, because it fixes a bug by removing code ;-)
When generating the initializer for a parameter array, we excepted
the case of size 0, which however prevented the detection of array
bounds violations and lead to ICEs in various places. The solution
which removes the comparison for size > 0 also has the bonus that
it fixes a minor memory leak for the size==0 case...
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 9d2995d2c1cf5708e3297fc7cffb5184d45a65cb Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 17 May 2023 20:39:18 +0200
Subject: [PATCH] Fortran: set shape of initializers of zero-sized arrays
[PR95374,PR104352]
gcc/fortran/ChangeLog:
PR fortran/95374
PR fortran/104352
* decl.cc (add_init_expr_to_sym): Set shape of initializer also for
zero-sized arrays, so that bounds violations can be detected later.
gcc/testsuite/ChangeLog:
PR fortran/95374
PR fortran/104352
* gfortran.dg/zero_sized_13.f90: New test.
---
gcc/fortran/decl.cc | 3 +--
gcc/testsuite/gfortran.dg/zero_sized_13.f90 | 28 +
2 files changed, 29 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/zero_sized_13.f90
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 9c4b40d4ac4..4c578d01ad4 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2239,8 +2239,7 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus)
&& gfc_is_constant_expr (init)
&& (init->expr_type == EXPR_CONSTANT
|| init->expr_type == EXPR_STRUCTURE)
- && spec_size (sym->as, )
- && mpz_cmp_si (size, 0) > 0)
+ && spec_size (sym->as, ))
{
array = gfc_get_array_expr (init->ts.type, init->ts.kind,
>where);
diff --git a/gcc/testsuite/gfortran.dg/zero_sized_13.f90 b/gcc/testsuite/gfortran.dg/zero_sized_13.f90
new file mode 100644
index 000..4035d458b32
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/zero_sized_13.f90
@@ -0,0 +1,28 @@
+! { dg-do compile }
+! { dg-options "-w" }
+!
+! PR fortran/95374
+! PR fortran/104352 - Various ICEs for bounds violation with zero-sized arrays
+!
+! Contributed by G. Steinmetz
+
+program p
+ implicit none
+ integer :: i
+ integer, parameter :: a(0)= 0
+ integer, parameter :: b(0:-5) = 0
+ integer, parameter :: c(*) = [(a(i:i), i=0,0)] ! { dg-error "out of bounds" }
+ integer, parameter :: d(*) = [(b(i:i), i=1,1)] ! { dg-error "out of bounds" }
+ integer, parameter :: e(1) = [(a(i) , i=1,1)] ! { dg-error "out of bounds" }
+ integer, parameter :: f(1) = [(a(i:i), i=1,1)] ! { dg-error "out of bounds" }
+ integer:: g(1) = [(a(i:i), i=0,0)] ! { dg-error "out of bounds" }
+ integer:: h(1) = [(a(i:i), i=1,1)] ! { dg-error "out of bounds" }
+ print *, [(a(i:i), i=0,0)] ! { dg-error "out of bounds" }
+ print *, [(a(i:i), i=1,1)] ! { dg-error "out of bounds" }
+ print *, any (a(1:1) == 1) ! { dg-error "out of bounds" }
+ print *, all (a(0:0) == 1) ! { dg-error "out of bounds" }
+ print *, sum (a(1:1)) ! { dg-error "out of bounds" }
+ print *, iall (a(0:0)) ! { dg-error "out of bounds" }
+ print *, minloc (a(0:0),1) ! { dg-error "out of bounds" }
+ print *, dot_product(a(1:1),a(1:1)) ! { dg-error "out of bounds" }
+end
--
2.35.3
Re: [PATCH 0/7] openmp: OpenMP 5.1 loop transformation directives
Hi Jakub,
On 16.05.23 13:00, Jakub Jelinek wrote:
On Tue, May 16, 2023 at 11:45:16AM +0200, Frederik Harwath wrote:
The place where different compilers implement the loop transformations
was discussed in an OpenMP loop transformation meeting last year. Two
compilers (another one and GCC with this patch series) transformed
the loops
in the middle end after the handling of data sharing, one planned to
do so.
Yet another vendor had not yet decided where it will be implemented.
Clang
currently does everything in the front end, but it was mentioned that
this
might change in the future e.g. for code sharing with Flang. Implementing
the loop transformations late could potentially
complicate the implementation of transformations which require
adjustments
of the data sharing clauses, but this is known and consequentially,
no such
When already in the FE we determine how many canonical loops a particular
loop transformation creates, I think the primary changes I'd like to
see is
really have OMP_UNROLL/OMP_TILE GENERIC statements (see below) and
consider
where is the best spot to lower it. I believe for data sharing it is best
done during gimplification before the containing loops are handled, it is
already shared code among all the FEs, I think will make it easier to
handle
data sharing right and gimplification is also where doacross processing is
done. While there is restriction that ordered clause is incompatible with
generated loops from tile construct, there isn't one for unroll (unless
"The ordered clause must not appear on a worksharing-loop directive if
the associated loops
include the generated loops of a tile directive."
means unroll partial implicitly because partial unroll tiles the loop, but
it doesn't say it acts as if it was a tile construct), so we'd have to
handle
#pragma omp for ordered(2)
for (int i = 0; i < 64; i++)
#pragma omp unroll partial(4)
for (int j = 0; j < 64; j++)
{
#pragma omp ordered depend (sink: i - 1, j - 2)
#pragma omp ordered depend (source)
}
and I think handling it after gimplification is going to be increasingly
harder. Of course another possibility is ask lang committee to clarify
unless it has been clarified already in 6.0 (but in TR11 it is not).
I do not really expect that we will have to handle this. Questions
concerning
the correctness of code after applying loop transformations came up several
times since I have been following the design meetings and the result was
always either that nothing will be changed, because the loop transformations
are not expected to ensure the correctness of enclosing directives, or that
the use of the problematic construct in conjunction with loop
transformations
will be forbidden. Concerning the use of "ordered" on transformed loops, the
latter approach was suggested for all transformations, cf. issue #3494
in the
private OpenMP spec repository. I see that you have already asked for
clarification
on unroll. I suppose this could also be fixed after gimplification with
reasonable effort. But let's just wait for the result of that discussion
before we
continue worrying about this.
Also, I think creating temporaries is easier to be done during
gimplification than later.
This has not caused problems with the current approach.
Another option is as you implemented a separate pre-omp-lowering pass,
and another one would be do it in the omplower pass, which has actually
several subpasses internally, do it in the scan phase. Disadvantage of
a completely separate pass is that we have to walk the whole IL again,
while doing it in the scan phase means we avoid that cost. We already
do there similar transformations, scan_omp_simd transforms simd constructs
into if (...) simd else simt and then we process it with normal
scan_omp_for
on what we've created. So, if you insist doing it after gimplification
perhaps for compatibility with other non-LLVM compilers, I'd prefer to
do it there rather than in a completely separate pass.
I see. This would be possible. My current approach is indeed rather
wasteful because the pass is not restricted to functions that actually
use loop transformations. I could add an attribute to such functions
that could be used to avoid the execution of the pass and hence
the gimple walk on functions that do not use transformations.
This is necessary to represent the loop nest that is affected by the
loop transformations by a single OMP_FOR to meet the expectations
of all later OpenMP code transformations. This is also the major
reason why the loop transformations are represented by clauses
instead of representing them as "OMP_UNROLL/OMP_TILE as
GENERIC constructs like OMP_FOR" as you suggest below. Since the
I really don't see why. We try to represent what we see in the source
as OpenMP constructs as those constructs. We already have a precedent
with composite loop constructs, where for the combined constructs which
aren't innermost we temporarily use NULL
[committed] Re: [Patch,v4] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings
The patch has now been committed as r14-931-g80bb0b8a81fdc5 The only change is that I added the &_P in 'if (sym->ts.deferred && VAR_P (length))' in trans-decl.cc just to avoid potential issues in case length is not a var decl (but e.g. a '0' tree node, cf. code). Tobias On 23.03.23 10:28, Tobias Burnus wrote: [...] Another update - fixing an independent issue which makes sense to be part of this patch. Allocatable/pointer scalars are currently mapped as: #pragma omp target enter data map(to:*var.1_1 [len: 4]) map(alloc:var [pointer assign, bias: 0]) #pragma omp target exit data map(from:*var.2_2 [len: 4]) where 'GOMP_MAP_POINTER' is removed in gimplify.cc. In v3 (and v4) of this patch, this kind of handling moved from gimplify.cc to fortran/trans-openmp.cc; however, v3 has the same problem. For allocatable arrays, we have PSET + POINTER and the PSET part is changed/set to RELEASE/DELETE for 'exit data' But for scalars, the map was still left on the stack. Besides having a stale map, this could lead to fails when the stack was popped, especially when attempting to later map another stack variable with the same stack address, partially overlapping with the stale POINTER. Side remark: I found this for testcase that is part of an upcoming deep-mapping follow-up patch; that test failed with -O1 but worked with -O0/-Og due to changed stack usage. (Deep-mapping of allocatable components is on the OG12 branch; it is scheduled for mainline integration after stage1 opened.) The updated mainline patch is included; map-10.f90 is the new testcase. If anyone wants to see it separately, the patch has been committed to OG12 as https://gcc.gnu.org/g:8ea805840200f7dfd2c11b37abf5fbfe479c2fe2 Comments/thoughts/remarks to this patch? Tobias PS: For the rest of the patch, see a short description below - or with some longer remarks previous in this thread. On 27.02.23 13:15, Tobias Burnus wrote: And another re-diff for GCC 13/mainline, updating gcc/testsuite/ (The last change is related to the "[OG12,committed] Update dg-dump-scan for ..." discussion + OG12 https://gcc.gnu.org/g:e4de87a2309 / https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612871.html ) On 23.02.23 17:42, Tobias Burnus wrote: On 21.02.23 12:57, Tobias Burnus wrote: This patch moves some generic code for Fortran out of gimplify.cc to trans-openmp.cc and fixes several issues related to mapping. Tested with nvptx offloading. OK for mainline? Tobias Caveats: Besides the issues shown in the comment-out code, there remains also an issue with implicit mapping - at least for deferred-length strings, but I wouldn't be surprised if - at least depending on the used 'defaultmap' value (e.g. 'alloc') - there are also issues with array descriptors. Note: Regarding the declare target check for mapping: Without declare target, my assumption is that the hidden length variable will get implicitly mapped if needed. Independent of deferred-length or not, there is probably an issue with 'defaultmap(none)' and the hidden variable. - In any case, I prefer to defer all those issues to later (by having them captured in one/several PR). Tobias PS: This patch is a follow up to [Patch] Fortran/OpenMP: Fix DT struct-component with 'alloc' and array descr https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604887.html which fixed part of the problems. But as discussed on IRC, it did treat 'alloc' as special and missed some other map types. - In addition, this patch has a much extended test coverage and fixes some more issues found that way. - 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 commit 80bb0b8a81fdc5d0a1c88ae3febd593868daa752 Author: Tobias Burnus Date: Wed May 17 12:28:14 2023 +0200 Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings Previously, array descriptors might have been mapped as 'alloc' instead of 'to' for 'alloc', not updating the array bounds. The 'alloc' could also appear for 'data exit', failing with a libgomp assert. In some cases, either array descriptors or deferred-length string's length variable was not mapped. And, finally, some offset calculations with array-sections mappings went wrong. Additionally, the patch now unmaps for scalar allocatables/pointers the GOMP_MAP_POINTER, avoiding stale mappings. The testcases contain some comment-out tests which require follow-up work and for which PR exist. Those mostly relate to deferred-length strings which have several issues beyong OpenMP support. gcc/fortran/ChangeLog: * trans-decl.cc (gfc_get_symbol_decl): Add attributes such as 'declare target' also to hidden artificial variable for deferred-length character
