[patch] Fortran/OpenMP: Support most of 5.1 atomic extensions
The basic support was lying around here already for too long.
TODO at some point: Update the trans-openmp.c part to handle compare +
extend the testcases even more, especially when compare works.
OK?
Tobias
-
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
Fortran/OpenMP: Support most of 5.1 atomic extensions
Implements moste of OpenMP 5.1 atomic extensions,
except that 'compare' is parsed but rejected during
resolution. (As the trans-openmp.c handling is missing.)
gcc/fortran/ChangeLog:
* dump-parse-tree.c (show_omp_clauses): Handle
weak/compare/fail clause.
* gfortran.h (gfc_omp_clauses): Add weak, compare, fail.
* openmp.c (enum omp_mask1, gfc_match_omp_clauses,
OMP_ATOMIC_CLAUSES): Update for new clauses.
(gfc_match_omp_atomic): Update for 5.1 atomic changes.
(is_conversion): Support widening in one go.
(is_scalar_intrinsic_expr): New.
(resolve_omp_atomic): Update for 5.1 atomic changes.
* parse.c (parse_omp_oacc_atomic): Update for compare.
* resolve.c (gfc_resolve_blocks): Update asserts.
* trans-openmp.c (gfc_trans_omp_atomic): Handle new clauses.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/atomic-2.f90: Move now supported code to ...
* gfortran.dg/gomp/atomic.f90: here.
* gfortran.dg/gomp/atomic-10.f90: New test.
* gfortran.dg/gomp/atomic-12.f90: New test.
* gfortran.dg/gomp/atomic-15.f90: New test.
* gfortran.dg/gomp/atomic-16.f90: New test.
* gfortran.dg/gomp/atomic-17.f90: New test.
* gfortran.dg/gomp/atomic-18.f90: New test.
* gfortran.dg/gomp/atomic-19.f90: New test.
* gfortran.dg/gomp/atomic-20.f90: New test.
* gfortran.dg/gomp/atomic-22.f90: New test.
* gfortran.dg/gomp/atomic-24.f90: New test.
* gfortran.dg/gomp/atomic-25.f90: New test.
* gfortran.dg/gomp/atomic-26.f90: New test.
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.1): Update status.
gcc/fortran/dump-parse-tree.c| 20 +
gcc/fortran/gfortran.h | 3 +-
gcc/fortran/intrinsic.c | 2 +-
gcc/fortran/openmp.c | 584 +--
gcc/fortran/parse.c | 19 +-
gcc/fortran/resolve.c| 9 +-
gcc/fortran/trans-openmp.c | 15 +-
gcc/testsuite/gfortran.dg/gomp/atomic-10.f90 | 32 ++
gcc/testsuite/gfortran.dg/gomp/atomic-12.f90 | 364 +
gcc/testsuite/gfortran.dg/gomp/atomic-15.f90 | 44 ++
gcc/testsuite/gfortran.dg/gomp/atomic-16.f90 | 36 ++
gcc/testsuite/gfortran.dg/gomp/atomic-17.f90 | 41 ++
gcc/testsuite/gfortran.dg/gomp/atomic-18.f90 | 27 ++
gcc/testsuite/gfortran.dg/gomp/atomic-19.f90 | 39 ++
gcc/testsuite/gfortran.dg/gomp/atomic-2.f90 | 42 +-
gcc/testsuite/gfortran.dg/gomp/atomic-20.f90 | 39 ++
gcc/testsuite/gfortran.dg/gomp/atomic-22.f90 | 24 ++
gcc/testsuite/gfortran.dg/gomp/atomic-24.f90 | 13 +
gcc/testsuite/gfortran.dg/gomp/atomic-25.f90 | 53 +++
gcc/testsuite/gfortran.dg/gomp/atomic-26.f90 | 75
gcc/testsuite/gfortran.dg/gomp/atomic.f90| 40 +-
gcc/testsuite/gfortran.dg/gomp/atomic2.f90 | 0
22 files changed, 1256 insertions(+), 265 deletions(-)
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 04660d5074a..34b332751d8 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -1810,6 +1810,10 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
}
fputc (')', dumpfile);
}
+ if (omp_clauses->weak)
+fputs (" WEAK", dumpfile);
+ if (omp_clauses->compare)
+fputs (" COMPARE", dumpfile);
if (omp_clauses->nogroup)
fputs (" NOGROUP", dumpfile);
if (omp_clauses->simd)
@@ -1926,6 +1930,22 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
fputc (' ', dumpfile);
fputs (memorder, dumpfile);
}
+ if (omp_clauses->fail != OMP_MEMORDER_UNSET)
+{
+ const char *memorder;
+ switch (omp_clauses->fail)
+ {
+ case OMP_MEMORDER_ACQ_REL: memorder = "ACQ_REL"; break;
+ case OMP_MEMORDER_ACQUIRE: memorder = "AQUIRE"; break;
+ case OMP_MEMORDER_RELAXED: memorder = "RELAXED"; break;
+ case OMP_MEMORDER_RELEASE: memorder = "RELEASE"; break;
+ case OMP_MEMORDER_SEQ_CST: memorder = "SEQ_CST"; break;
+ default: gcc_unreachable ();
+ }
+ fputs (" FAIL(", dumpfile);
+ fputs (memorder, dumpfile);
+ putc (')', dumpfile);
+}
if (omp_clauses->at != OMP_AT_UNSET)
{
if (omp_clauses->at != OMP_AT_COMPILATION)
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 1ad2f0df702..54bdd5ab2e5 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1526,10 +1526,11 @@ typedef struct gfc_omp_clauses
unsigned sched_simd:1, sched_monotonic:1, sched_nonmonotonic:1;
unsigned simd:1, threads:1, depend_source:1, destroy:1, order_concurrent
GCC 12.0.0 Status Report (2021-11-15), Stage 3 in effect NOW
Status == The GCC development branch now is open for general bugfixing (Stage 3). Take the quality data below with a big grain of salt - most of the new P3 classified bugs will become P1 or P2 (generally every regression against GCC 11 is to be considered P1 if it concerns primary or secondary platforms). Quality Data Priority # Change from last report --- --- P1 34 + 19 P2 306 + 24 P3 237 + 44 P4 207 + 5 P5 25 --- --- Total P1-P3 577 + 87 Total 809 + 92 Previous Report === https://gcc.gnu.org/pipermail/gcc/2021-October/237464.html
Re: GCC 12.0.0 Status Report (2021-11-15), Stage 3 in effect NOW
On Mon, Nov 15, 2021 at 4:05 AM Richard Biener via Gcc-patches wrote: > > > Status > == > > The GCC development branch now is open for general bugfixing (Stage 3). > > Take the quality data below with a big grain of salt - most of the > new P3 classified bugs will become P1 or P2 (generally every > regression against GCC 11 is to be considered P1 if it concerns > primary or secondary platforms). > > > Quality Data > > > Priority # Change from last report > --- --- > P1 34 + 19 > P2 306 + 24 > P3 237 + 44 > P4 207 + 5 > P5 25 > --- --- > Total P1-P3 577 + 87 > Total 809 + 92 > > > Previous Report > === > > https://gcc.gnu.org/pipermail/gcc/2021-October/237464.html Hi, I'd like to add an option to disable copy relocation: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583022.html Thanks. -- H.J.
Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes
Hi, is there an update on this? I am still waiting on a response for the account on the development machine. I assume we would to the development on a branch. My git fu is extremely weak, so I would appreciate if somebody did that for me. Is it actually possible to implement what I wrote in the draft documentation patch, or is there some problem (like gmp or mpfr depending on one of the types at compile-time)? If so, I think we should go for it; if not, then we have to make another decision. Due to my day job, my time for working on this project is rather limited, and in my experience it is easier to finish something if it is actually started :-) So, who does what? I work on the gfortran internals (library interface) and the library itself, but I would need some prior work to set up the compiler so things work up to that particular point. Or have we missed the window due to gcc being in stage 3 now? Best regards Thomas
[PATCH] PR fortran/99061 - [10/11/12 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728
Dear Fortranners,
the attached patch fixes the handling of the DEC trigonometric intrinsics
for different argument kinds. It is based on the original patch by Steve,
which fixes the lookup for the needed intrinsics.
Regtested on x86_64-pc-linux-gnu. OK for affected branches?
Thanks,
Harald
From e979db00b8e84333c53bc0b8f1c89cd8ce18d72c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 15 Nov 2021 22:32:17 +0100
Subject: [PATCH] Fortran: fix lookup for gfortran builtin math intrinsics used
by DEC extensions
gcc/fortran/ChangeLog:
PR fortran/99061
* trans-intrinsic.c (gfc_lookup_intrinsic): Helper function for
looking up gfortran builtin intrinsics.
(gfc_conv_intrinsic_atrigd): Use it.
(gfc_conv_intrinsic_cotan): Likewise.
(gfc_conv_intrinsic_cotand): Likewise.
(gfc_conv_intrinsic_atan2d): Likewise.
gcc/testsuite/ChangeLog:
PR fortran/99061
* gfortran.dg/dec_math_5.f90: New test.
---
gcc/fortran/trans-intrinsic.c| 66 ---
gcc/testsuite/gfortran.dg/dec_math_5.f90 | 103 +++
2 files changed, 138 insertions(+), 31 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/dec_math_5.f90
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 3f867911af5..bd67f4f44da 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -4555,6 +4555,18 @@ rad2deg (int kind)
}
+static gfc_intrinsic_map_t *
+gfc_lookup_intrinsic (gfc_isym_id id)
+{
+ gfc_intrinsic_map_t *m = gfc_intrinsic_map;
+ for (; m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++)
+if (id == m->id)
+ break;
+ gcc_assert (id == m->id);
+ return m;
+}
+
+
/* ACOSD(x) is translated into ACOS(x) * 180 / pi.
ASIND(x) is translated into ASIN(x) * 180 / pi.
ATAND(x) is translated into ATAN(x) * 180 / pi. */
@@ -4565,20 +4577,27 @@ gfc_conv_intrinsic_atrigd (gfc_se * se, gfc_expr * expr, gfc_isym_id id)
tree arg;
tree atrigd;
tree type;
+ gfc_intrinsic_map_t *m;
type = gfc_typenode_for_spec (&expr->ts);
gfc_conv_intrinsic_function_args (se, expr, &arg, 1);
- if (id == GFC_ISYM_ACOSD)
-atrigd = gfc_builtin_decl_for_float_kind (BUILT_IN_ACOS, expr->ts.kind);
- else if (id == GFC_ISYM_ASIND)
-atrigd = gfc_builtin_decl_for_float_kind (BUILT_IN_ASIN, expr->ts.kind);
- else if (id == GFC_ISYM_ATAND)
-atrigd = gfc_builtin_decl_for_float_kind (BUILT_IN_ATAN, expr->ts.kind);
- else
-gcc_unreachable ();
-
+ switch (id)
+{
+case GFC_ISYM_ACOSD:
+ m = gfc_lookup_intrinsic (GFC_ISYM_ACOS);
+ break;
+case GFC_ISYM_ASIND:
+ m = gfc_lookup_intrinsic (GFC_ISYM_ASIN);
+ break;
+case GFC_ISYM_ATAND:
+ m = gfc_lookup_intrinsic (GFC_ISYM_ATAN);
+ break;
+default:
+ gcc_unreachable ();
+}
+ atrigd = gfc_get_intrinsic_lib_fndecl (m, expr);
atrigd = build_call_expr_loc (input_location, atrigd, 1, arg);
se->expr = fold_build2_loc (input_location, MULT_EXPR, type, atrigd,
@@ -4614,13 +4633,9 @@ gfc_conv_intrinsic_cotan (gfc_se *se, gfc_expr *expr)
mpfr_clear (pio2);
/* Find tan builtin function. */
- m = gfc_intrinsic_map;
- for (; m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++)
- if (GFC_ISYM_TAN == m->id)
- break;
-
- tmp = fold_build2_loc (input_location, PLUS_EXPR, type, arg, tmp);
+ m = gfc_lookup_intrinsic (GFC_ISYM_TAN);
tan = gfc_get_intrinsic_lib_fndecl (m, expr);
+ tmp = fold_build2_loc (input_location, PLUS_EXPR, type, arg, tmp);
tan = build_call_expr_loc (input_location, tan, 1, tmp);
se->expr = fold_build1_loc (input_location, NEGATE_EXPR, type, tan);
}
@@ -4630,20 +4645,12 @@ gfc_conv_intrinsic_cotan (gfc_se *se, gfc_expr *expr)
tree cos;
/* Find cos builtin function. */
- m = gfc_intrinsic_map;
- for (; m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++)
- if (GFC_ISYM_COS == m->id)
- break;
-
+ m = gfc_lookup_intrinsic (GFC_ISYM_COS);
cos = gfc_get_intrinsic_lib_fndecl (m, expr);
cos = build_call_expr_loc (input_location, cos, 1, arg);
/* Find sin builtin function. */
- m = gfc_intrinsic_map;
- for (; m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++)
- if (GFC_ISYM_SIN == m->id)
- break;
-
+ m = gfc_lookup_intrinsic (GFC_ISYM_SIN);
sin = gfc_get_intrinsic_lib_fndecl (m, expr);
sin = build_call_expr_loc (input_location, sin, 1, arg);
@@ -4675,11 +4682,7 @@ gfc_conv_intrinsic_cotand (gfc_se *se, gfc_expr *expr)
mpfr_clear (ninety);
/* Find tand. */
- gfc_intrinsic_map_t *m = gfc_intrinsic_map;
- for (; m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++)
-if (GFC_ISYM_TAND == m->id)
- break;
-
+ gfc_intrinsic_map_t *m = gfc_lookup_intrinsic (GFC_ISYM_TAND);
tree tand = gfc_get_intrinsic_lib_fndecl (m, expr);
tand = build_call_expr_loc (input_location, tand, 1, arg)
Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes
On 11/15/21 2:27 PM, Thomas Koenig wrote: > I am still waiting on a response for the account on the development machine. I haven't heard anything about the P9 partition either. I'll ping OSU about that now. Peter
Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes
On Mon, Nov 15, 2021 at 09:27:38PM +0100, Thomas Koenig wrote: > Hi, > > is there an update on this? I am still waiting on a response for > the account on the development machine. > > I assume we would to the development on a branch. My git fu > is extremely weak, so I would appreciate if somebody did that > for me. Sure, we can create an IBM vendor branch. > Is it actually possible to implement what I wrote in the draft > documentation patch, or is there some problem (like gmp > or mpfr depending on one of the types at compile-time)? > > If so, I think we should go for it; if not, then we have to make > another decision. Well there are a couple of things that need to be done. A lot are fortran specific type things, so while I can attempt to do these things, I don't know the structure of the front end or library. >From my previous test patches, I think it is a disaster if KIND=16 is not the same as C/C++ long double by default. It opens up all sorts of problems. But then it may be the Fortran users would like that flexibility. That is your call. I think the most important thing is defining the library interface and naming scheme. So we need to switch calls to one name or another based on the default long double format. I don't know what naming scheme you use, but it should be fairly simple. For the C/C++/math built-ins, we use the traditional name with an 'l' suffix if long double is IBM double-double, and a 'f128' suffix if long double is IEEE 128-bit. The PowerPC backend will automatically switch names for built-ins it knows about. However, my tests showed there are a bunch of functions that are in the math library that are not built-ins. For C/C++, this is not an issue, because math.h will do this switching. We would need some way for Fortran to do it for the other functions. Once we have the naming scheme, then we need to modify the library build, so that it will build both types of modules with the appropriate flags. Once the library is set up to have both names, then we can start to think about the user overriding the defaults. This is probably a thing that needs the Fortran folk to do, since there may be various rules of what can be done. But for the initial work, I think the most important thing is getting the library so it has both names in it, so a user/distro could start to move the default floating point type. > Due to my day job, my time for working on this project is rather > limited, and in my experience it is easier to finish something if > it is actually started :-) > > So, who does what? I work on the gfortran internals (library interface) > and the library itself, but I would need some prior work to set up the > compiler so things work up to that particular point. > > Or have we missed the window due to gcc being in stage 3 now? This may be an issue for the release and Fortran maintainers. Even if we can't put it in right now, I think it is important to start work so it can be put in at a later date. In terms of my schedule, I will be available for doing whatever is needed until December 20th. I have a hard stop then as I will be doing a family trip for Christmas and I will not be available after that. I won't be back until the new year. I believe Bill and Peter feel this is one of the most important uses of my time in the next month or so. But bear in mind, I don't know much about the Fortran front end, nothing about the library, or knowing Fortran at all. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes
On 16.11.21 00:42, Michael Meissner wrote: On Mon, Nov 15, 2021 at 09:27:38PM +0100, Thomas Koenig wrote: Hi, is there an update on this? I am still waiting on a response for the account on the development machine. I assume we would to the development on a branch. My git fu is extremely weak, so I would appreciate if somebody did that for me. Sure, we can create an IBM vendor branch. Is it actually possible to implement what I wrote in the draft documentation patch, or is there some problem (like gmp or mpfr depending on one of the types at compile-time)? If so, I think we should go for it; if not, then we have to make another decision. Well there are a couple of things that need to be done. A lot are fortran specific type things, so while I can attempt to do these things, I don't know the structure of the front end or library. From my previous test patches, I think it is a disaster if KIND=16 is not the same as C/C++ long double by default. It opens up all sorts of problems. But then it may be the Fortran users would like that flexibility. That is your call. I think the most important thing is defining the library interface and naming scheme. So we need to switch calls to one name or another based on the default long double format. I don't know what naming scheme you use, but it should be fairly simple. For the C/C++/math built-ins, we use the traditional name with an 'l' suffix if long double is IBM double-double, and a 'f128' suffix if long double is IEEE 128-bit. The PowerPC backend will automatically switch names for built-ins it knows about. That is where I come in, I think. However, my tests showed there are a bunch of functions that are in the math library that are not built-ins. For C/C++, this is not an issue, because math.h will do this switching. We would need some way for Fortran to do it for the other functions. OK. Looking at a random sample, libgfortran/generated/maxloc0_4_r4.c , has #if defined (HAVE_GFC_REAL_4) && defined (HAVE_GFC_INTEGER_4) extern void maxloc0_4_r4 (gfc_array_i4 * const restrict retarray, gfc_array_r4 * const restrict array, GFC_LOGICAL_4); which is expanded by m4 from maxloc0.m4, which in turn includes iforeach.m4, which has name`'rtype_qual`_'atype_code (rtype * const restrict retarray, atype * const restrict array, GFC_LOGICAL_4 back) where the parameters are determined from the file name. So we can put in a file maxloc0_4_r17 into the normal build process, which will give us #if defined (HAVE_GFC_REAL_17) && defined (HAVE_GFC_INTEGER_4) Next thing to do would be to put the file into libgfortran/Makefile.am, making sure that it is compiled with the right options. There will have to be some condition on the compilation that we do not compile the files on non-POWER-systems. Next, we need to define GFC_REAL_17 as IEEE QP on POWER (only there of course), probably in libgfortran/kinds-override.h. For compiling, there has to be a flag in the compiler to let us know what we are compiling for, so we can call the different functions depending on the flag. Once we have the naming scheme, then we need to modify the library build, so that it will build both types of modules with the appropriate flags. Yep. Once the library is set up to have both names, then we can start to think about the user overriding the defaults. This is probably a thing that needs the Fortran folk to do, since there may be various rules of what can be done. But for the initial work, I think the most important thing is getting the library so it has both names in it, so a user/distro could start to move the default floating point type. I can start working on that, once the following are in (or documented): - A global configure script that determines if there is a target which supports both IEEE QP and double double. - A conditional suitable for Makefile.am on libgfortran to check for that condition - A preprocessor directive in the compiler to check if IEEE and QP are supported with the right flag - A compiler flag to select either IEEE QP or double double as default - A global flag to check if IEEE or double double is enabled Due to my day job, my time for working on this project is rather limited, and in my experience it is easier to finish something if it is actually started :-) So, who does what? I work on the gfortran internals (library interface) and the library itself, but I would need some prior work to set up the compiler so things work up to that particular point. Or have we missed the window due to gcc being in stage 3 now? This may be an issue for the release and Fortran maintainers. Even if we can't put it in right now, I think it is important to start work so it can be put in at a later date. I'd say we would need a global reviewer's OK for that, plus of course from a POWER maintainer, but that should not be a problem :-) In terms of my schedule, I will be available for doing whatever is needed unti
