Re: [power-ieee128] What should the math functions be annotated with?
On Fri, Dec 03, 2021 at 08:29:53AM +0100, Thomas Koenig wrote: > > On 01.12.21 21:54, Jakub Jelinek via Fortran wrote: > > > Inside of libgfortran, I think it should depend on some macro defined > > in libgfortran.h. > > #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \ > > && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32) > > then > > #define MATHFUNC(funcname) __ ## funcname ## ieee128 > > (i.e. use the functions that will be used when one uses e.g. > > sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure > > if those need to be declared by libgfortran or math.h declares them). > > Otherwise (when libgfortran is compiled against glibc older than 2.32) > > it should use > > #define MATHFUNC(funcname) funcname ## q > > i.e. use the libquadmath APIs). > > The current Ubuntu does not have these functions: > > ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$ nm libm.a 2>/dev/null | grep > ieee128 > ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$ > > Will they be supplied in the future, or with the advanced toolchain? It is part of upstream glibc 2.32 (released Aug 2020) and later, see https://sourceware.org/git/?p=glibc.git;a=commit;h=051be01f6b41a1466b07ae4bd7f5894a8ec5fe67 distrowatch says that glibc 2.32 and later is in Ubuntu 21.04 and later. Jakub
Re: [power-ieee128] What should the math functions be annotated with?
On 03.12.21 10:28, Jakub Jelinek wrote: On Fri, Dec 03, 2021 at 08:29:53AM +0100, Thomas Koenig wrote: On 01.12.21 21:54, Jakub Jelinek via Fortran wrote: Inside of libgfortran, I think it should depend on some macro defined in libgfortran.h. #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \ && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32) then #define MATHFUNC(funcname) __ ## funcname ## ieee128 (i.e. use the functions that will be used when one uses e.g. sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure if those need to be declared by libgfortran or math.h declares them). Otherwise (when libgfortran is compiled against glibc older than 2.32) it should use #define MATHFUNC(funcname) funcname ## q i.e. use the libquadmath APIs). The current Ubuntu does not have these functions: ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$ nm libm.a 2>/dev/null | grep ieee128 ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$ Will they be supplied in the future, or with the advanced toolchain? It is part of upstream glibc 2.32 (released Aug 2020) and later, see https://sourceware.org/git/?p=glibc.git;a=commit;h=051be01f6b41a1466b07ae4bd7f5894a8ec5fe67 distrowatch says that glibc 2.32 and later is in Ubuntu 21.04 and later. Jakub So it is not possible to test on the current machine set up for this, which has ubuntu 20.04. This makes development rather pointless at the moment :-( So, what should the path forward be?
Re: [power-ieee128] What should the math functions be annotated with?
On Fri, Dec 03, 2021 at 12:16:56PM +0100, Thomas Koenig wrote: > > It is part of upstream glibc 2.32 (released Aug 2020) and later, see > > https://sourceware.org/git/?p=glibc.git;a=commit;h=051be01f6b41a1466b07ae4bd7f5894a8ec5fe67 > > distrowatch says that glibc 2.32 and later is in Ubuntu 21.04 and later. > > So it is not possible to test on the current machine set up for this, > which has ubuntu 20.04. This makes development rather pointless at > the moment :-( > > So, what should the path forward be? glibc is backwards compatible, so if whomever has root on the machine would just upgrade glibc, that would be enough. I don't know if ubuntu has something like mock(1) that allows just installing packages from a newer distro in a new chroot, that would be another option. One can also just as a user unpack newer glibc somewhere, configure gcc against that tree as --with-sysroot= but for running tests one would need to change dynamic_linker_prefix in specs - *dynamic_linker_prefix: /home/user/wherever in some file and -specs=/that/file but it would be a pain. Note, we want to test both building gcc on ppc64le with older glibc and newer glibc (and that libgfortran will have the same ABI between both and one can move gcc including libgfortran and libquadmath from the older glibc setup to newer and make -mabi=ieeelongdouble work in Fortran too). Jakub
Re: [power-ieee128] What should the math functions be annotated with?
Hi Jakub, Note, we want to test both building gcc on ppc64le with older glibc and newer glibc (and that libgfortran will have the same ABI between both and one can move gcc including libgfortran and libquadmath from the older glibc setup to newer and make -mabi=ieeelongdouble work in Fortran too). Using an older glibc is no problem - we can use gcc135 on the compile farm for that. As far as the other options you outlined, I think I'll defer to people who know more about setting up libraries than I do. I have root access, but chances are I would just mess up the virtual machine :-) Regards Thomas
Re: [PATCH] PR fortran/103505 - ICE in compare_bound_mpz_t, at fortran/resolve.c:4587
On 02/12/2021 22:48, Harald Anlauf via Fortran wrote: Dear Fortranners, specifying invalid constant array declarations (e.g. real array bounds) could lead to an ICE because the array specs were checked for consistency. A possible solution is to try an early simplification before doing that check and was suggested by Steve. However, regtesting did reveal that bad declarations involving e.g. arithmetic errors - like division by zero - were now handled differently. (The relevant testcase was gfortran.dg/arith_divide_2.f90). I therefore added a new function gfc_try_simplify_expr that accepts the simplification only if no error occurs. This allows discovery of arithmetic errors also at later stages and will be used here. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK. Thanks
Re: [patch] Fortran/OpenMP: Support most of 5.1 atomic extensions
On Mon, Nov 15, 2021 at 12:29:31PM +0100, Tobias Burnus wrote:
> --- a/gcc/fortran/dump-parse-tree.c
> +++ b/gcc/fortran/dump-parse-tree.c
> @@ -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;
No need for the above line.
> + case OMP_MEMORDER_ACQUIRE: memorder = "AQUIRE"; break;
> + case OMP_MEMORDER_RELAXED: memorder = "RELAXED"; break;
> + case OMP_MEMORDER_RELEASE: memorder = "RELEASE"; break;
And above line either. They aren't allowed for fail clause and
you reject it already during parsing, so the default: gcc_unreachable ();
can handle it fine.
> + case OMP_MEMORDER_SEQ_CST: memorder = "SEQ_CST"; break;
> + default: gcc_unreachable ();
> @@ -1449,8 +1452,9 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
> omp_mask mask,
>gcc_checking_assert (OMP_MASK1_LAST <= 64 && OMP_MASK2_LAST <= 64);
>*cp = NULL;
>while (1)
> -{
> - if ((first || gfc_match_char (',') != MATCH_YES)
> +{
Why the added trailing whitespace after { ?
> + match m = MATCH_NO;
> + if ((first || (m = gfc_match_char (',')) != MATCH_YES)
> && (needs_space && gfc_match_space () != MATCH_YES))
> break;
>needs_space = false;
> @@ -1460,7 +1464,11 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
> omp_mask mask,
>gfc_omp_namelist **head;
>old_loc = gfc_current_locus;
>char pc = gfc_peek_ascii_char ();
> - match m;
> + if (pc == '\n' && m == MATCH_YES)
> + {
> + gfc_error ("Clause expected at %C after tailing comma");
Do you mean trailing ?
> + if ((mask & OMP_CLAUSE_FAIL)
> + && (m = gfc_match_dupl_check (c->fail == OMP_MEMORDER_UNSET,
> + "fail", true)) != MATCH_NO)
> + {
> + if (m == MATCH_ERROR)
> + goto error;
> + if (gfc_match ("seq_cst") == MATCH_YES)
> + c->fail = OMP_MEMORDER_SEQ_CST;
> + else if (gfc_match ("acquire") == MATCH_YES)
> + c->fail = OMP_MEMORDER_ACQUIRE;
> + else if (gfc_match ("relaxed") == MATCH_YES)
> + c->fail = OMP_MEMORDER_RELAXED;
> + else
> + {
> + gfc_error ("Expected SEQ_CST, ACQUIRE or RELAXED at %C");
> + break;
> + }
Here is where you make sure c->fail isn't OMP_MEMORDER_{RELEASE,ACQ_REL} ...
> -static void
> +/*static */ void
> resolve_omp_atomic (gfc_code *code)
Why?
> + if (stmt && !capture_stmt && next->block->block)
> + {
> + if (next->block->block->expr1)
> + {
> + gfc_error ("Expected ELSE at %L in atomic compare capture",
> + &next->block->block->expr1->where);
> + }
No {}s around single statement body.
> @@ -4508,6 +4508,17 @@ gfc_trans_omp_atomic (gfc_code *code)
> case OMP_MEMORDER_SEQ_CST: mo = OMP_MEMORY_ORDER_SEQ_CST; break;
> default: gcc_unreachable ();
> }
> + switch (atomic_code->ext.omp_clauses->fail)
> +{
> +case OMP_MEMORDER_UNSET: fail_mo = OMP_FAIL_MEMORY_ORDER_UNSPECIFIED;
> break;
> +case OMP_MEMORDER_ACQ_REL: fail_mo = OMP_FAIL_MEMORY_ORDER_RELAXED;
> break;
> +case OMP_MEMORDER_ACQUIRE: fail_mo = OMP_FAIL_MEMORY_ORDER_ACQUIRE;
> break;
> +case OMP_MEMORDER_RELAXED: fail_mo = OMP_FAIL_MEMORY_ORDER_RELAXED;
> break;
> +case OMP_MEMORDER_RELEASE: fail_mo = OMP_FAIL_MEMORY_ORDER_RELEASE;
> break;
> +case OMP_MEMORDER_SEQ_CST: fail_mo = OMP_FAIL_MEMORY_ORDER_SEQ_CST;
> break;
Again, no reason to handle OMP_MEMORDER_ACQ_REL and OMP_MEMORDER_RELEASE
above.
Otherwise LGTM.
Jakub
Re: [power-ieee128] What should the math functions be annotated with?
Hi! On 12/3/21 5:56 AM, Thomas Koenig wrote: > > Hi Jakub, > >> Note, we want to test both building gcc on ppc64le with older glibc >> and newer glibc (and that libgfortran will have the same ABI between both >> and one can move gcc including libgfortran and libquadmath from the older >> glibc setup to newer and make -mabi=ieeelongdouble work in Fortran too). > > Using an older glibc is no problem - we can use gcc135 on the compile > farm for that. > > As far as the other options you outlined, I think I'll defer to people > who know more about setting up libraries than I do. I have root access, > but chances are I would just mess up the virtual machine :-) Easiest is probably to install the advance toolchain. Mike said he'll work on that later this morning. Thanks! Bill > > Regards > > Thomas
Re: [PATCH, v2, OpenMP 5.0] Remove array section base-pointer mapping semantics, and other front-end adjustments (mainline trunk)
On Fri, Nov 19, 2021 at 09:54:12PM +0800, Chung-Lin Tang wrote:
> 2021-11-19 Chung-Lin Tang
>
> gcc/c/ChangeLog:
>
> * c-parser.c (struct omp_dim): New struct type for use inside
> c_parser_omp_variable_list.
> (c_parser_omp_variable_list): Allow multiple levels of array and
> component accesses in array section base-pointer expression.
> (c_parser_omp_clause_to): Set 'allow_deref' to true in call to
> c_parser_omp_var_list_parens.
> (c_parser_omp_clause_from): Likewise.
> * c-typeck.c (handle_omp_array_sections_1): Extend allowed range
> of base-pointer expressions involving INDIRECT/MEM/ARRAY_REF and
> POINTER_PLUS_EXPR.
> (c_finish_omp_clauses): Extend allowed ranged of expressions
> involving INDIRECT/MEM/ARRAY_REF and POINTER_PLUS_EXPR.
>
> gcc/cp/ChangeLog:
>
> * parser.c (struct omp_dim): New struct type for use inside
> cp_parser_omp_var_list_no_open.
> (cp_parser_omp_var_list_no_open): Allow multiple levels of array and
> component accesses in array section base-pointer expression.
> (cp_parser_omp_all_clauses): Set 'allow_deref' to true in call to
> cp_parser_omp_var_list for to/from clauses.
> * semantics.c (handle_omp_array_sections_1): Extend allowed range
> of base-pointer expressions involving INDIRECT/MEM/ARRAY_REF and
> POINTER_PLUS_EXPR.
> (handle_omp_array_sections): Adjust pointer map generation of
> references.
> (finish_omp_clauses): Extend allowed ranged of expressions
> involving INDIRECT/MEM/ARRAY_REF and POINTER_PLUS_EXPR.
>
> gcc/fortran/ChangeLog:
>
> * trans-openmp.c (gfc_trans_omp_array_section): Do not generate
> GOMP_MAP_ALWAYS_POINTER map for main array maps of ARRAY_TYPE type.
>
> gcc/ChangeLog:
>
> * gimplify.c (extract_base_bit_offset): Add 'tree *offsetp' parameter,
> accomodate case where 'offset' return of get_inner_reference is
> non-NULL.
> (is_or_contains_p): Further robustify conditions.
> (omp_target_reorder_clauses): In alloc/to/from sorting phase, also
> move following GOMP_MAP_ALWAYS_POINTER maps along. Add new sorting
> phase where we make sure pointers with an attach/detach map are ordered
> correctly.
> (gimplify_scan_omp_clauses): Add modifications to avoid creating
> GOMP_MAP_STRUCT and associated alloc map for attach/detach maps.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/goacc/deep-copy-arrayofstruct.c: Adjust testcase.
> * c-c++-common/gomp/target-enter-data-1.c: New testcase.
> * c-c++-common/gomp/target-implicit-map-2.c: New testcase.
>
> libgomp/ChangeLog:
>
> * target.c (gomp_map_vars_existing): Make sure attached pointer is
> not overwritten during cross-host/device copying.
> (gomp_update): Likewise.
> (gomp_exit_data): Likewise.
> * testsuite/libgomp.c++/target-11.C: Adjust testcase.
> * testsuite/libgomp.c++/target-12.C: Likewise.
> * testsuite/libgomp.c++/target-15.C: Likewise.
> * testsuite/libgomp.c++/target-16.C: Likewise.
> * testsuite/libgomp.c++/target-17.C: Likewise.
> * testsuite/libgomp.c++/target-21.C: Likewise.
> * testsuite/libgomp.c++/target-23.C: Likewise.
> * testsuite/libgomp.c/target-23.c: Likewise.
> * testsuite/libgomp.c/target-29.c: Likewise.
> * testsuite/libgomp.c-c++-common/target-implicit-map-2.c: New testcase.
> @@ -12982,6 +12991,7 @@ c_parser_omp_variable_list (c_parser *parser,
>
>while (1)
> {
> + auto_vec dims;
>bool array_section_p = false;
>if (kind == OMP_CLAUSE_DEPEND || kind == OMP_CLAUSE_AFFINITY)
> {
Wouldn't it be better to have the dims variable outside of the loop?
You do dims.truncate (0); anyway, so when it is used, it should always
start with an empty vector, but if it is outside of the loop, it won't
need to be freed and allocated again for every list item.
> + else
> + {
> + for (unsigned i = 0; i < dims.length (); i++)
> + t = tree_cons (dims[i].low_bound, dims[i].length, t);
> + }
No {}s around single statement body.
> static tree
> cp_parser_omp_var_list_no_open (cp_parser *parser, enum omp_clause_code kind,
> tree list, bool *colon,
> bool allow_deref = false)
> {
> + auto_vec dims;
> + bool array_section_p;
>cp_token *token;
>bool saved_colon_corrects_to_scope_p = parser->colon_corrects_to_scope_p;
>if (colon)
Here it is correctly outside of the loop ;)
Otherwise LGTM.
Jakub
Re: [power-ieee128] What should the math functions be annotated with?
On Fri, Dec 03, 2021 at 08:57:54AM -0600, Bill Schmidt wrote:
> Hi!
>
> On 12/3/21 5:56 AM, Thomas Koenig wrote:
> >
> > Hi Jakub,
> >
> >> Note, we want to test both building gcc on ppc64le with older glibc
> >> and newer glibc (and that libgfortran will have the same ABI between both
> >> and one can move gcc including libgfortran and libquadmath from the older
> >> glibc setup to newer and make -mabi=ieeelongdouble work in Fortran too).
> >
> > Using an older glibc is no problem - we can use gcc135 on the compile
> > farm for that.
> >
> > As far as the other options you outlined, I think I'll defer to people
> > who know more about setting up libraries than I do. I have root access,
> > but chances are I would just mess up the virtual machine :-)
>
> Easiest is probably to install the advance toolchain. Mike said he'll work on
>
> that later this morning.
>
> Thanks!
> Bill
I have loaded Advance Toolchain 15.0 on the system. It is located in
/opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
I built a trunk compiler using the options:
--enable-languages=c,c++,fortran \
--disable-plugin \
--enable-checking \
--enable-stage1-checking \
--enable-gnu-indirect-function \
--disable-libgomp \
--enable-decimal-float \
--enable-secureplt \
--enable-threads=posix \
--enable-__cxa_atexit \
--with-cpu=power8 \
--with-long-double-128 \
--with-as=/opt/at15.0/bin/as \
--with-ld=/opt/at15.0/bin/ld \
--with-gnu-as=/opt/at15.0/bin/as \
--with-gnu-ld=/opt/at15.0/bin/ld \
--with-advance-toolchain=at15.0 \
--with-system-zlib \
--with-native-system-header-dir=/opt/at15.0/include \
--without-ppl \
--without-cloog \
--without-isl
I will rebuild the compiler using --with-cpu=power9 instead, since if power9 is
the default CPU, we avoid the use of using an emulator for IEEE 128-bit.
Note, if you are doing a bootstrap using the AT 15.0 libraries, you need a
'msgfmt' in your PATH to avoid problems that show up when the compiler is
rebuilding libstdc++. I use this script:
#! /bin/bash
# Hack script to allow building GCC with the --with-advance-toolchain=
# option and do a bootstrap. What happens is at the end of the stage1 build,
# and in preparation for the stage2 build, the environment variable
# LD_LIBRARY_PATH is set to the new library directory. Unfortunately this
# occurs while we are building libstdc++, and the libstdc++ that is pointed to
# is incomplete. The msgfmt program then aborts because it doesn't have the
# right symbols. This script allows us to not use those environment variables.
unset LD_LIBRARY_PATH
unset RPATH_ENVVAR
for x in /usr/local/bin /usr/bin /bin; do
if [ -x "${x}/msgfmt" ]; then
exec "${x}/msgfmt" $@
fi
done
echo "Could not find msgfmt" >&2
exit 1
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
