[patch, committed] fortran/intrinsic.texi: Fix copy'n'paste errors and typos (was: https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gfortran/)
Hi Johannes, hi all,
On 24.05.21 23:21, Johannes Nendwich wrote:
some more suggestions for corrections in the onlinedocs:
thanks for the proof reading.
I have converted it into a patch and committed it as attached.
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
commit 2044a3e3e8343d047344523a1cca98309ce68fdc
Author: Tobias Burnus
Date: Tue May 25 09:17:07 2021 +0200
fortran/intrinsic.texi: Fix copy'n'paste errors and typos
gcc/fortran/ChangeLog:
* intrinsic.texi (GERROR, GETARGS, GETLOG, NORM2, PARITY, RANDOM_INIT,
RANDOM_NUMBER): Fix typos and copy'n'paste errors.
Co-Authored-By: Johannes Nendwich
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index ad164137986..c9049b539d5 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -6835,7 +6835,7 @@ Subroutine
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
-@item @var{RESULT} @tab Shall of type @code{CHARACTER} and of default
+@item @var{RESULT} @tab Shall be of type @code{CHARACTER} and of default kind.
@end multitable
@item @emph{Example}:
@@ -6885,7 +6885,6 @@ Subroutine
the default integer kind; @math{@var{POS} \geq 0}
@item @var{VALUE} @tab Shall be of type @code{CHARACTER} and of default
kind.
-@item @var{VALUE} @tab Shall be of type @code{CHARACTER}.
@end multitable
@item @emph{Return value}:
@@ -7259,7 +7258,7 @@ Subroutine
@end multitable
@item @emph{Return value}:
-Stores the current user name in @var{LOGIN}. (On systems where POSIX
+Stores the current user name in @var{C}. (On systems where POSIX
functions @code{geteuid} and @code{getpwuid} are not available, and
the @code{getlogin} function is not implemented either, this will
return a blank string.)
@@ -11202,7 +11201,7 @@ end program test_nint
@table @asis
@item @emph{Description}:
-Calculates the Euclidean vector norm (@math{L_2} norm) of
+Calculates the Euclidean vector norm (@math{L_2} norm)
of @var{ARRAY} along dimension @var{DIM}.
@item @emph{Standard}:
@@ -11555,7 +11554,7 @@ Transformational function
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
-@item @var{LOGICAL} @tab Shall be an array of type @code{LOGICAL}
+@item @var{MASK} @tab Shall be an array of type @code{LOGICAL}
@item @var{DIM} @tab (Optional) shall be a scalar of type
@code{INTEGER} with a value in the range from 1 to n, where n
equals the rank of @var{MASK}.
@@ -12005,7 +12004,7 @@ is set to a processor-dependent value.
@code{LOGICAL} type, and it is @code{INTENT(IN)}. If it is @code{.true.},
the seed is set to a processor-dependent value that is distinct from th
seed set by a call to @code{RANDOM_INIT} in another image. If it is
-@code{.false.}, the seed is set value that does depend which image called
+@code{.false.}, the seed is set to a value that does depend which image called
@code{RANDOM_INIT}.
@end multitable
@@ -12057,7 +12056,7 @@ Fortran 90 and later
Subroutine
@item @emph{Syntax}:
-@code{RANDOM_NUMBER(HARVEST)}
+@code{CALL RANDOM_NUMBER(HARVEST)}
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
[PATCH, OpenMP 5.0] Remove array section base-pointer mapping semantics, and other front-end adjustments (mainline trunk)
Hi Jakub,
this is a version of this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570075.html
for mainline trunk.
This patch largely implements three pieces of functionality:
(1) Per discussion and clarification on the omp-lang mailing list,
standards conforming behavior for mapping array sections should *NOT* also map
the base-pointer,
i.e for this code:
struct S { int *ptr; ... };
struct S s;
#pragma omp target enter data map(to: s.ptr[:100])
Currently we generate after gimplify:
#pragma omp target enter data map(struct:s [len: 1]) map(alloc:s.ptr [len: 8]) \
map(to:*_1 [len: 400]) map(attach:s.ptr [bias:
0])
which is deemed incorrect. After this patch, the gimplify results are now
adjusted to:
#pragma omp target enter data map(to:*_1 [len: 400]) map(attach:s.ptr [bias: 0])
(the attach operation is still generated, and if s.ptr is already mapped prior,
attachment will happen)
The correct way of achieving the base-pointer-also-mapped behavior would be to
use:
#pragma omp target enter data map(to: s.ptr, s.ptr[:100])
This adjustment in behavior required a number of small adjustments here and
there in gimplify, including
to accomodate map sequences for C++ references.
There is also a small Fortran front-end patch involved (hence CCing Tobias and
fortran@).
The new gimplify processing changed behavior in handling
GOMP_MAP_ALWAYS_POINTER maps such that
the libgomp.fortran/struct-elem-map-1.f90 regressed. It appeared that the
Fortran FE was generating
a GOMP_MAP_ALWAYS_POINTER for array types, which didn't seem quite correct, and
the pre-patch behavior
was removing this map anyways. I have a small change in
trans-openmp.c:gfc_trans_omp_array_section
to not generate the map in this case, and so far no bad test results.
(2) The second part (though kind of related to the first above) are fixes in
libgomp/target.c
to not overwrite attached pointers when handling device<->host copies, mainly for the
"always" case.
This behavior is also noted in the 5.0 spec, but not yet properly coded before.
(3) The third is a set of changes to the C/C++ front-ends to extend the allowed
component access syntax
in map clauses. This is actually mainly an effort to allow SPEC HPC to compile,
so despite in the long
term the entire map clause syntax parsing is probably going to be revamped,
we're still adding this in
for now. These changes are enabled for both OpenACC and OpenMP.
Tested on x86_64-linux with nvptx offloading with no regressions. This patch
was merged and tested atop
of the prior submitted patches:
(a) https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570886.html
"[PATCH, OpenMP 5.0] Improve OpenMP target support for C++ (includes PR92120
v3)"
(b) https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570365.html
"[PATCH, OpenMP 5.0] Implement relaxation of implicit map vs. existing device
mappings (for mainline trunk)"
so you might queued this one later than those for review.
Thanks,
Chung-Lin
2021-05-25 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.
PING [PATCH] PR fortran/100602 - [11/12 Regression] Erroneous "pointer argument is not associated" runtime error
*PING* > Gesendet: Dienstag, 18. Mai 2021 um 20:36 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR fortran/100602 - [11/12 Regression] Erroneous "pointer > argument is not associated" runtime error > > The generation of the new runtime check picked up the wrong attributes > in the case of CLASS array arguments. There is related new code in > gfc_conv_procedure_call which served as reference for the fix. > > Regtested on x86_64-pc-linux-gnu. > > OK for mainline / 11-branch? > > Thanks, > Harald > > > Fortran: Fix erroneous "pointer argument is not associated" runtime error > > For CLASS arrays we need to use the CLASS data attributes to determine > which runtime check to generate. > > gcc/fortran/ChangeLog: > > PR fortran/100602 > * trans-intrinsic.c (gfc_conv_intrinsic_size): Use CLASS data > attributes for CLASS arrays for generation of runtime error. > > gcc/testsuite/ChangeLog: > > PR fortran/100602 > * gfortran.dg/pointer_check_14.f90: New test. > >
