public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [Fortran, patch, coarray, v1] Fix a coarray issue and some documentation
@ 2018-02-11 17:13 Andre Vehreschild
  2018-02-11 19:00 ` Andre Vehreschild
  0 siblings, 1 reply; 3+ messages in thread
From: Andre Vehreschild @ 2018-02-11 17:13 UTC (permalink / raw)
  To: GCC-Patches-ML, GCC-Fortran-ML

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

Hi all,

attached patch fixes a small coarray issue on ultimate component coarrays. The
coarray was registered with the caf-library as if it were an allocatable
component in a derived type coarray, which is just wasting resources. An
ultimate component coarray has to be treated like a regular coarray. The second
chunk of the patch fixes that.

The first chunk of the attached patch just fixes some typos and style I found
while reading the help text for caf_register(). Those are so small that I did
not want to add another patch for this, given that both parts of the patch are
somehow related.

Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk?

Regards,
	Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

[-- Attachment #2: caf_nullify_and_doc_fix_v1.clog --]
[-- Type: application/octet-stream, Size: 276 bytes --]

gcc/fortran/ChangeLog:

2018-02-11  Andre Vehreschild  <vehre@gcc.gnu.org>

	* gfortran.texi: Fix typos in documentation of caf_register ().
	* trans-array.c (structure_alloc_comps): Only register a component of
	a derived typed corray, not of an ultimate component coarray.


[-- Attachment #3: caf_nullify_and_doc_fix_v1.patch --]
[-- Type: text/x-patch, Size: 3676 bytes --]

diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 11246696e18..9ffe6ade661 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -4453,8 +4453,8 @@ is not used then.  On the contrary when
 @code{CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY} is specified, then the
 @var{token} needs to be registered by a previous call with regtype
 @code{CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY} and either the memory specified
-in the @var{desc}'s data-ptr is registered or allocate when the data-ptr is
-NULL.
+in the @var{DESC}'s data-ptr is registered or allocate when the data-ptr is
+@code{NULL}.
 
 @item @emph{Syntax}:
 @code{void caf_register (size_t size, caf_register_t type, caf_token_t *token,
@@ -4468,24 +4468,24 @@ allocated; for lock types and event types, the number of elements.
 @item @var{token} @tab intent(out) An opaque pointer identifying the coarray.
 @item @var{desc} @tab intent(inout) The (pseudo) array descriptor.
 @item @var{stat} @tab intent(out) For allocatable coarrays, stores the STAT=;
-may be NULL
+may be @code{NULL}
 @item @var{errmsg} @tab intent(out) When an error occurs, this will be set to
-an error message; may be NULL
+an error message; may be @code{NULL}
 @item @var{errmsg_len} @tab the buffer size of errmsg.
 @end multitable
 
 @item @emph{NOTES}
-Nonalloatable coarrays have to be registered prior use from remote images.
+Nonallocatable coarrays have to be registered prior use from remote images.
 In order to guarantee this, they have to be registered before the main
 program. This can be achieved by creating constructor functions. That is what
-GCC does such that also nonallocatable coarrays the memory is allocated and no
-static memory is used.  The token permits to identify the coarray; to the
+GCC does such that also for nonallocatable coarrays the memory is allocated and
+no static memory is used.  The token permits to identify the coarray; to the
 processor, the token is a nonaliasing pointer. The library can, for instance,
 store the base address of the coarray in the token, some handle or a more
 complicated struct.  The library may also store the array descriptor
 @var{DESC} when its rank is non-zero.
 
-For lock types, the value shall only used for checking the allocation
+For lock types, the value shall only be used for checking the allocation
 status. Note that for critical blocks, the locking is only required on one
 image; in the locking statement, the processor shall always pass an
 image index of one for critical-block lock variables
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index d8b4381251e..4ffda26ca7d 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8747,15 +8747,17 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
 	      cmp_has_alloc_comps = false;
 	    }
 
-	  if (flag_coarray == GFC_FCOARRAY_LIB
-	      && (caf_in_coarray (caf_mode) || c->attr.codimension))
+	  if (flag_coarray == GFC_FCOARRAY_LIB && caf_in_coarray (caf_mode))
 	    {
-	      /* Register the component with the coarray library.  */
+	      /* Register a component of a derived type coarray with the
+		 coarray library.  Do not register ultimate component
+		 coarrays here.  They are treated like regular coarrays and
+		 are either allocated on all images or on none.  */
 	      tree token;
 
 	      comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
 				      decl, cdecl, NULL_TREE);
-	      if (c->attr.dimension || c->attr.codimension)
+	      if (c->attr.dimension)
 		{
 		  /* Set the dtype, because caf_register needs it.  */
 		  gfc_add_modify (&fnblock, gfc_conv_descriptor_dtype (comp),

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Fortran, patch, coarray, v1] Fix a coarray issue and some documentation
  2018-02-11 17:13 [Fortran, patch, coarray, v1] Fix a coarray issue and some documentation Andre Vehreschild
@ 2018-02-11 19:00 ` Andre Vehreschild
  2018-02-11 19:16   ` Andre Vehreschild
  0 siblings, 1 reply; 3+ messages in thread
From: Andre Vehreschild @ 2018-02-11 19:00 UTC (permalink / raw)
  To: GCC-Patches-ML, GCC-Fortran-ML

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

Hi all,

approved on IRC by Kargl. Thanks for the quick review. Committed as r

Regards,
	Andre

On Sun, 11 Feb 2018 18:13:35 +0100
Andre Vehreschild <vehre@gmx.de> wrote:

> Hi all,
> 
> attached patch fixes a small coarray issue on ultimate component coarrays. The
> coarray was registered with the caf-library as if it were an allocatable
> component in a derived type coarray, which is just wasting resources. An
> ultimate component coarray has to be treated like a regular coarray. The
> second chunk of the patch fixes that.
> 
> The first chunk of the attached patch just fixes some typos and style I found
> while reading the help text for caf_register(). Those are so small that I did
> not want to add another patch for this, given that both parts of the patch are
> somehow related.
> 
> Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk?
> 
> Regards,
> 	Andre


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

[-- Attachment #2: submit.diff --]
[-- Type: text/x-patch, Size: 4089 bytes --]

Index: gcc/fortran/ChangeLog
===================================================================
--- gcc/fortran/ChangeLog	(Revision 257566)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,9 @@
+2018-02-11  Andre Vehreschild  <vehre@gcc.gnu.org>
+
+	* gfortran.texi: Fix typos in documentation of caf_register ().
+	* trans-array.c (structure_alloc_comps): Only register a component of
+	a derived typed corray, not of an ultimate component coarray.
+
 2018-02-11  Steven G. Kargl  <kargl@gcc.gnu.org>
 
 	PR fortran/54223
Index: gcc/fortran/gfortran.texi
===================================================================
--- gcc/fortran/gfortran.texi	(Revision 257566)
+++ gcc/fortran/gfortran.texi	(Arbeitskopie)
@@ -4453,8 +4453,8 @@
 @code{CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY} is specified, then the
 @var{token} needs to be registered by a previous call with regtype
 @code{CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY} and either the memory specified
-in the @var{desc}'s data-ptr is registered or allocate when the data-ptr is
-NULL.
+in the @var{DESC}'s data-ptr is registered or allocate when the data-ptr is
+@code{NULL}.
 
 @item @emph{Syntax}:
 @code{void caf_register (size_t size, caf_register_t type, caf_token_t *token,
@@ -4468,24 +4468,24 @@
 @item @var{token} @tab intent(out) An opaque pointer identifying the coarray.
 @item @var{desc} @tab intent(inout) The (pseudo) array descriptor.
 @item @var{stat} @tab intent(out) For allocatable coarrays, stores the STAT=;
-may be NULL
+may be @code{NULL}
 @item @var{errmsg} @tab intent(out) When an error occurs, this will be set to
-an error message; may be NULL
+an error message; may be @code{NULL}
 @item @var{errmsg_len} @tab the buffer size of errmsg.
 @end multitable
 
 @item @emph{NOTES}
-Nonalloatable coarrays have to be registered prior use from remote images.
+Nonallocatable coarrays have to be registered prior use from remote images.
 In order to guarantee this, they have to be registered before the main
 program. This can be achieved by creating constructor functions. That is what
-GCC does such that also nonallocatable coarrays the memory is allocated and no
-static memory is used.  The token permits to identify the coarray; to the
+GCC does such that also for nonallocatable coarrays the memory is allocated and
+no static memory is used.  The token permits to identify the coarray; to the
 processor, the token is a nonaliasing pointer. The library can, for instance,
 store the base address of the coarray in the token, some handle or a more
 complicated struct.  The library may also store the array descriptor
 @var{DESC} when its rank is non-zero.
 
-For lock types, the value shall only used for checking the allocation
+For lock types, the value shall only be used for checking the allocation
 status. Note that for critical blocks, the locking is only required on one
 image; in the locking statement, the processor shall always pass an
 image index of one for critical-block lock variables
Index: gcc/fortran/trans-array.c
===================================================================
--- gcc/fortran/trans-array.c	(Revision 257566)
+++ gcc/fortran/trans-array.c	(Arbeitskopie)
@@ -8747,15 +8747,17 @@
 	      cmp_has_alloc_comps = false;
 	    }
 
-	  if (flag_coarray == GFC_FCOARRAY_LIB
-	      && (caf_in_coarray (caf_mode) || c->attr.codimension))
+	  if (flag_coarray == GFC_FCOARRAY_LIB && caf_in_coarray (caf_mode))
 	    {
-	      /* Register the component with the coarray library.  */
+	      /* Register a component of a derived type coarray with the
+		 coarray library.  Do not register ultimate component
+		 coarrays here.  They are treated like regular coarrays and
+		 are either allocated on all images or on none.  */
 	      tree token;
 
 	      comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
 				      decl, cdecl, NULL_TREE);
-	      if (c->attr.dimension || c->attr.codimension)
+	      if (c->attr.dimension)
 		{
 		  /* Set the dtype, because caf_register needs it.  */
 		  gfc_add_modify (&fnblock, gfc_conv_descriptor_dtype (comp),

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Fortran, patch, coarray, v1] Fix a coarray issue and some documentation
  2018-02-11 19:00 ` Andre Vehreschild
@ 2018-02-11 19:16   ` Andre Vehreschild
  0 siblings, 0 replies; 3+ messages in thread
From: Andre Vehreschild @ 2018-02-11 19:16 UTC (permalink / raw)
  To: GCC-Patches-ML, GCC-Fortran-ML

Er, the revision is 257567. Sorry pressed to quickly.

- Andre

On Sun, 11 Feb 2018 20:00:05 +0100
Andre Vehreschild <vehre@gmx.de> wrote:

> Hi all,
> 
> approved on IRC by Kargl. Thanks for the quick review. Committed as r
> 
> Regards,
> 	Andre
> 
> On Sun, 11 Feb 2018 18:13:35 +0100
> Andre Vehreschild <vehre@gmx.de> wrote:
> 
> > Hi all,
> > 
> > attached patch fixes a small coarray issue on ultimate component coarrays.
> > The coarray was registered with the caf-library as if it were an allocatable
> > component in a derived type coarray, which is just wasting resources. An
> > ultimate component coarray has to be treated like a regular coarray. The
> > second chunk of the patch fixes that.
> > 
> > The first chunk of the attached patch just fixes some typos and style I
> > found while reading the help text for caf_register(). Those are so small
> > that I did not want to add another patch for this, given that both parts of
> > the patch are somehow related.
> > 
> > Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk?
> > 
> > Regards,
> > 	Andre  
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-02-11 19:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-11 17:13 [Fortran, patch, coarray, v1] Fix a coarray issue and some documentation Andre Vehreschild
2018-02-11 19:00 ` Andre Vehreschild
2018-02-11 19:16   ` Andre Vehreschild

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).