Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier

[Andre Vehreschild]

Whoops, hi Damian,

sorry for my late reply. I just saw your mail. I am still hanging ~2000
Fortran-Mailinglist mails back and because you copied the mailing list, your
mail got filtered to the mailing list folder and I didn't see it in the vast
number or unread mails.

> Thanks for your latest work on CAF features.  Could you let us know whether
> this commit should be tested against the OpenCoarrays master branch or
> another branch?  With the master branch, I get one test failure (not counting
> two known teams failures that are actually false negatives that I need to
> fix):
> 
> lib_caf_mpi::sendget_by_ref(): Warning ! sendget_by_ref() is mostly
> unfunctional due to a design error. Split up your statement with coarray refs
> on both sides of the assignment when the datatype transfered is non
> 4-byte-integer compatible. libcaf_mpi RUNTIME ERROR: Cannot convert type 1
> kind 4 to type 0 kind 4
> 
> Is the above expected?  Also, because the message comes from sendget, does
> that mean it only affects lines that involve three images such as the
> following:
> 
> if (this_image()==1) x[2] = x[3]

You may test this patch against OpenCoarrays, but without having OC patched it
will not benefit from it. I prepared the gfortran patch to fix exactly the
above error, but haven't had the time to fix Opencoarrays, too. I'd rather get
a better gfortran-8 up and therefore am trying to get pr81773 and 83606 fixed
and get them merged into gfortran-8.

I follow this strategy, because gcc release cycles are less flexible then OCs.
So as soon as I get 81773 and 83606 fixed, I will come back to OC fixing the
type issues.

Sorry for the delayed response. My time is very limited and this last gfortran
fix involved the scalarizer which is a very complicated concept in the gfortran
and I haven't worked with before, therefore a steep learning curve. I hope to
be on track more often soon.

- Andre

> 
> 
> Damian
> 
> On February 19, 2018 at 9:32:06 AM, Andre Vehreschild (ve...@gmx.de) wrote:
> 
> Hi all,  
> 
> no objections received therefore committed as r257813. Thanks for fast
> review Jerry.  
> 
> - Andre  
> 
> On Sun, 18 Feb 2018 18:33:07 +0100  
> Andre Vehreschild  wrote:  
> 
> > Well, after discussing on IRC whether RM should be bothered, I was asked
> > to simplify release managers lives and propose, that if no one objects
> > within one day, I will merge the patch. So any objections?  
> >  
> > - Andre  
> >  
> > On Sun, 18 Feb 2018 18:07:28 +0100  
> > Andre Vehreschild  wrote:  
> >
> > > Dear release managers,  
> > >  
> > > this patch (for reference  
> > > https://gcc.gnu.org/ml/fortran/2018-02/msg00124.html) fixes a regression
> > > in the coarray api by extending three relatively new functions with one
> > > or two arguments, respectively. The patch has been approved by gfortran
> > > devs. Asking your approval to merge it: Ok to merge to trunk?  
> > >  
> > > Regards,  
> > > Andre  
> > >  
> > > On Sun, 18 Feb 2018 08:53:41 -0800  
> > > Jerry DeLisle  wrote:  
> > >
> > > > On 02/18/2018 07:39 AM, Andre Vehreschild wrote:
> > > > > Hi all,  
> > > > >  
> > > > > attached patch fixes an issue with the coarray API. When a component
> > > > > of a derived type coarray was referenced using a caf_*_by_ref ()
> > > > > function and that component was not an array with a descriptor, then
> > > > > the type of the component was not known. Which additionally meant,
> > > > > that type conversion was not applied as required. This patch fixes
> > > > > that issue by adding type specifiers to the three caf_*_by_ref-calls
> > > > > and implements the functionality for libcaf_single. This is harmless
> > > > > because other coarray libraries that do not expect this argument just
> > > > > ignore it. Additionally does this patch also provide the first
> > > > > working version of caf_sendget_by_ref in libcaf_single, which
> > > > > previously only lead to a stack corruption and was not usable since
> > > > > the array descriptor rework (nice job, btw).  
> > > > >  
> > > > > I would like to have this patch in trunk knowing that I am somewhat  
> > > > > late, but it would be quite necessary, because as it is now, the  
> > > > > coarray feature for derived types is hardly usable. Furthermore do
> > > > > some people name this a regression, because the caf_*_by_ref are also
> > > > > used when the lhs of a caf_get_by_ref() is allocatable which now does
> > > > > not work as expected anymore but before gcc-6 using caf_get() (w/o  
> > > > > reallocation) did.  
> > > > >  
> > > > > Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?  
> > > > >  
> > > > > - Andre  
> > > > >
> > > >  
> > > > This is OK from the Fortranners perspective. Should touch base with  
> > > > release manager. It looks harmless though it changes coarray API,
> > > > which is hidden behind -fcoarray=  
> > > >  
> > > > Regards,  
> > > >  
> > > > Jerry   

Re: [committed] fix a couple of typos in manual

[Martin Sebor]

On 04/07/2018 05:43 PM, Gerald Pfeifer wrote:

On Mon, 2 Apr 2018, Martin Sebor wrote:

I committed r259020 to fix a couple of typos in the documentation
of the -Wrestrict option.  The diff is below for reference.



-The @option{-Wrestrict} is included in @option{-Wall}.
+The @option{-Wrestrict} option detects some instances of simple overlap
+even without optimization but works best at @option{-O2}.  It is included
+in @option{-Wall}.


Shoulds this read "-O2 or higher"?


I suppose it would be more accurate that way.  I've added it to
both -Wrestrict and -fprintf-return-value in r259224.


(That's an interesting definition of typo, by the way. ;-)  Not
disputing the change as such, only the ChangeLog entry.)


The typo was in the example.  (Of course, I managed to introduce
a new one while fixing it...)  The new sentence was incidental.

Martin

PS While looking around for other examples of "-O2 and above"
I came across a number of other similarly incomplete lists of
optimization options.  I posted a separate patch to update those.

[PATCH/doc] - mention all optimization options that enable inlining options

[Martin Sebor]

While updating the -Wrestrict option to mention that it works
best not just with -O2 but also at higher optimization levels
I looked around for other options that might benefit from
a similar clarification.  I found a few inlining options that
only mention -O2 but that (according to -Q --help=optimizers)
are enabled at other levels as well.  The attached patch
changes the manual to reflect that.

Given the large number of options I didn't take the time to
check all optimization options so there could others that could
stand to be similarly improved if we want to be 100% accurate.
If that is, in fact, what we want then we might want to script
this.

Martin
2018-04-08  Martin Sebor  

	* invoke.texi (-finline-small-functions): Mention other optimization
	options.
	(-findirect-inlining, -fpartial-inlining): Same.
	(-finline-functions-called-once): Same.
	(-freorder-blocks-and-partition): Same.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 259224)
+++ gcc/doc/invoke.texi	(working copy)
@@ -7780,7 +7780,7 @@ heuristically decides which functions are simple e
 in this way.  This inlining applies to all functions, even those not declared
 inline.
 
-Enabled at level @option{-O2}.
+Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
 
 @item -findirect-inlining
 @opindex findirect-inlining
@@ -7789,7 +7789,7 @@ time thanks to previous inlining.  This option has
 when inlining itself is turned on by the @option{-finline-functions}
 or @option{-finline-small-functions} options.
 
-Enabled at level @option{-O2}.
+Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
 
 @item -finline-functions
 @opindex finline-functions
@@ -7801,7 +7801,7 @@ If all calls to a given function are integrated, a
 declared @code{static}, then the function is normally not output as
 assembler code in its own right.
 
-Enabled at level @option{-O3}.
+Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
 
 @item -finline-functions-called-once
 @opindex finline-functions-called-once
@@ -9002,7 +9002,7 @@ Inline parts of functions.  This option has any ef
 when inlining itself is turned on by the @option{-finline-functions}
 or @option{-finline-small-functions} options.
 
-Enabled at level @option{-O2}.
+Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
 
 @item -fpredictive-commoning
 @opindex fpredictive-commoning
@@ -9109,7 +9109,7 @@ sections.  When @option{-fsplit-stack} is used thi
 enabled by default (to avoid linker errors), but may be enabled
 explicitly (if using a working linker).
 
-Enabled for x86 at levels @option{-O2}, @option{-O3}.
+Enabled for x86 at levels @option{-O2}, @option{-O3}, @option{-Os}.
 
 @item -freorder-functions
 @opindex freorder-functions

Re: [nvptx, PR81352] Add exit insn after noreturn call for neutered threads in warp

[Gerald Pfeifer]

On Wed, 24 Jan 2018, Tom de Vries wrote:
> On 01/24/2018 12:53 PM, Richard Biener wrote:
>> wrong-code bugs qualify for stage4 if a fix isn't too invasive.  Target
>> maintainers have an extra say to override stage4 rules anyway and for
>> non-primary/secondary targets nobody cares anyway.
> Maybe then we should be more clear then in formulation of stage 4 criteria?

Richi?  I did not see anyone approve or reject Tom's patch, and it
did not make it into the tree.

What is your take?  (It's fine as far as wwwdocs go, but this really
is a question on the RMs.)

Gerald

> [ Change validated as XHTML 1.0 Transitional ]
> 
> Index: htdocs/develop.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
> retrieving revision 1.178
> diff -u -r1.178 develop.html
> --- htdocs/develop.html   15 Jan 2018 08:23:26 -  1.178
> +++ htdocs/develop.html   24 Jan 2018 13:40:30 -
> @@ -130,10 +130,10 @@
>  Stage 4
> 
>  During this period, the only (non-documentation) changes that may
> -be made are changes that fix regressions.  Other changes may not be
> -done during this period.  Note that the same constraints apply
> -to release branches.  This period lasts until stage 1 opens for
> -the next release.
> +be made are changes that fix regressions, or that fix wrong-code bugs
> +in a non-invasive way.  Other changes may not be done during this
> +period.  Note that the same constraints apply to release branches.
> +This period lasts until stage 1 opens for the next release.
> 
>  Rationale

Re: [wwwdocs] gcc-8/changes.html additions

[Gerald Pfeifer]

On Sat, 7 Apr 2018, Bernd Edlinger wrote:
>> I seem to have a writer's block right now, or I would have proposed
>> a full alternative, but hope the above gives you an indication?
> Thanks for your review!
> 
> I committed the other parts and rewrote this one along your
> suggested wording.  See attached patch.
> 
> Is it OK?

Yours is definitely better than what I failed to come up with
yesterday, Bernd.

I suggest you change "and the size of the element it points to"
to "by the size of the elements it points to" (divide by, and
plural for elements) and go ahead and commit.

Thanks for your patience.

Gerald

Re: [wwwdocs] Update gcc-8/changes.html for some IPA and x86 canges

[Gerald Pfeifer]

On Sun, 8 Apr 2018, Richard Biener wrote:
>> I struggled a bit parsing the item DWARF debug information
>> improvements.
>> Are you fine with the proposed change below?
> Sure! Go ahead.

Thanks!  

Before committing I read it again and simplified a bit. Below the 
final version.

Gerald
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.50
diff -u -r1.50 changes.html
--- changes.html1 Apr 2018 22:19:57 -   1.50
+++ changes.html8 Apr 2018 12:40:08 -
@@ -72,10 +72,10 @@
 
   Link-time optimization improvements:
   
-On ELF targets using DWARF debug information has been significantly
-improved in quality by properly preserving language-specific
-   debug information.  This allows for example the libstdc++
-   pretty-printers to work with LTO optimized executables.
+We have significantly improved debug information on ELF targets
+using DWARF by properly preserving language-specific information.
+This allows for example the libstdc++ pretty-printers to work with
+LTO optimized executables.
   
   
 A new option -fcf-protection=[full|branch|return|none] is

[Fortran, Patch, PR81773, PR83606, coarray, v1] Fix coarray get to array with vector indexing

[Andre Vehreschild]

Hi all,

attached patch fixes (to my knowledge) the two PRs 81773 and 83606 where the
result of a coarray get() operation is assigned to an array using a vector as
index.  It took me quite long to get it right, because I had to use the
scalarizer which I haven't use directly before. So reviewers with expertise on
using the scalarizer are especially welcome.

Bootstrapped and regtested on x86_64-linux/f27.

Ok for trunk? Backports?

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2018-04-08  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
* dependency.c (gfc_dep_resolver): Coarray indexes are to be ignored
during dependency computation.  They define no data dependency.
* trans-array.c (conv_array_index_offset): The stride can not be set
here, prevent fail.
* trans-intrinsic.c (conv_caf_send): Add creation of temporary array
for caf_get's result and copying to the array with vectorial
indexing.

gcc/testsuite/ChangeLog:

2018-04-08  Andre Vehreschild  

PR fortran/81773
PR fortran/83606
* gfortran.dg/coarray/get_to_indexed_array_1.f90: New test.
* gfortran.dg/coarray/get_to_indirect_array.f90: New test.

diff --git a/gcc/fortran/dependency.c b/gcc/fortran/dependency.c
index a0bbd584947..3e14ddc25d8 100644
--- a/gcc/fortran/dependency.c
+++ b/gcc/fortran/dependency.c
@@ -2238,8 +2238,9 @@ gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse)
 	break;
 
 	  /* Exactly matching and forward overlapping ranges don't cause a
-	 dependency.  */
-	  if (fin_dep < GFC_DEP_BACKWARD)
+	 dependency, when they are not part of a coarray ref.  */
+	  if (fin_dep < GFC_DEP_BACKWARD
+	  && lref->u.ar.codimen == 0 && rref->u.ar.codimen == 0)
 	return 0;
 
 	  /* Keep checking.  We only have a dependency if
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index bd731689031..b68e77d5281 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -3215,7 +3215,7 @@ conv_array_index_offset (gfc_se * se, gfc_ss * ss, int dim, int i,
 }
 
   /* Multiply by the stride.  */
-  if (!integer_onep (stride))
+  if (stride != NULL && !integer_onep (stride))
 index = fold_build2_loc (input_location, MULT_EXPR, gfc_array_index_type,
 			 index, stride);
 
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index a45aec708fb..00edd447bb2 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1907,34 +1907,124 @@ conv_caf_send (gfc_code *code) {
 }
   else
 {
-  /* If has_vector, pass descriptor for whole array and the
- vector bounds separately.  */
-  gfc_array_ref *ar, ar2;
-  bool has_vector = false;
+  bool has_vector = gfc_has_vector_subscript (lhs_expr);
 
-  if (gfc_is_coindexed (lhs_expr) && gfc_has_vector_subscript (lhs_expr))
+  if (gfc_is_coindexed (lhs_expr) || !has_vector)
 	{
-  has_vector = true;
-  ar = gfc_find_array_ref (lhs_expr);
-	  ar2 = *ar;
-	  memset (ar, '\0', sizeof (*ar));
-	  ar->as = ar2.as;
-	  ar->type = AR_FULL;
+	  /* If has_vector, pass descriptor for whole array and the
+	 vector bounds separately.  */
+	  gfc_array_ref *ar, ar2;
+	  bool has_tmp_lhs_array = false;
+	  if (has_vector)
+	{
+	  has_tmp_lhs_array = true;
+	  ar = gfc_find_array_ref (lhs_expr);
+	  ar2 = *ar;
+	  memset (ar, '\0', sizeof (*ar));
+	  ar->as = ar2.as;
+	  ar->type = AR_FULL;
+	}
+	  lhs_se.want_pointer = 1;
+	  gfc_conv_expr_descriptor (_se, lhs_expr);
+	  /* Using gfc_conv_expr_descriptor, we only get the descriptor, but
+	 that has the wrong type if component references are done.  */
+	  lhs_type = gfc_typenode_for_spec (_expr->ts);
+	  tmp = build_fold_indirect_ref_loc (input_location, lhs_se.expr);
+	  gfc_add_modify (_se.pre, gfc_conv_descriptor_dtype (tmp),
+			  gfc_get_dtype_rank_type (has_vector ? ar2.dimen
+			  : lhs_expr->rank,
+		   lhs_type));
+	  if (has_tmp_lhs_array)
+	{
+	  vec = conv_caf_vector_subscript (, lhs_se.expr, );
+	  *ar = ar2;
+	}
 	}
-  lhs_se.want_pointer = 1;
-  gfc_conv_expr_descriptor (_se, lhs_expr);
-  /* Using gfc_conv_expr_descriptor, we only get the descriptor, but that
- has the wrong type if component references are done.  */
-  lhs_type = gfc_typenode_for_spec (_expr->ts);
-  tmp = build_fold_indirect_ref_loc (input_location, lhs_se.expr);
-  gfc_add_modify (_se.pre, gfc_conv_descriptor_dtype (tmp),
-  gfc_get_dtype_rank_type (has_vector ? ar2.dimen
-			  : lhs_expr->rank,
-		  lhs_type));
-  if (has_vector)
+  else
 	{
-	  vec = conv_caf_vector_subscript (, lhs_se.expr, );
-	  *ar = ar2;
+	  /* Special casing for arr1 ([...]) = arr2[...], i.e. caf_get to
+	 indexed 

New Swedish PO file for 'gcc' (version 8.1-b20180401)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-8.1-b20180401.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [committed] fix a couple of typos in manual

[Richard Biener]

On April 8, 2018 1:43:00 AM GMT+02:00, Gerald Pfeifer  
wrote:
>On Mon, 2 Apr 2018, Martin Sebor wrote:
>> I committed r259020 to fix a couple of typos in the documentation
>> of the -Wrestrict option.  The diff is below for reference.
>
>> -The @option{-Wrestrict} is included in @option{-Wall}.
>> +The @option{-Wrestrict} option detects some instances of simple
>overlap
>> +even without optimization but works best at @option{-O2}.  It is
>included
>> +in @option{-Wall}.
>
>Shoulds this read "-O2 or higher"?

Most certainly. 

>(That's an interesting definition of typo, by the way. ;-)  Not 
>disputing the change as such, only the ChangeLog entry.)
>
>Gerald

Re: [wwwdocs] Update gcc-8/changes.html for some IPA and x86 canges

[Richard Biener]

On April 7, 2018 11:11:05 PM GMT+02:00, Gerald Pfeifer  
wrote:
>On Tue, 20 Mar 2018, Richard Biener wrote:
>> I have committed the following (will happily edit if necessary).
>
>Thanks, Richard!
>
>I struggled a bit parsing the item DWARF debug information
>improvements.
>Are you fine with the proposed change below?

Sure! Go ahead. 

Richard. 

>Gerald
>
>Index: changes.html
>===
>RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
>retrieving revision 1.50
>diff -u -r1.50 changes.html
>--- changes.html   1 Apr 2018 22:19:57 -   1.50
>+++ changes.html   7 Apr 2018 21:09:53 -
>@@ -72,10 +72,11 @@
> 
>   Link-time optimization improvements:
>   
>-On ELF targets using DWARF debug information has been
>significantly
>-improved in quality by properly preserving language-specific
>-  debug information.  This allows for example the libstdc++
>-  pretty-printers to work with LTO optimized executables.
>+We have significantly improved debug information on ELF
>targets
>+using DWARF debug information by properly preserving
>+language-specific information.  This allows for example the
>+libstdc++ pretty-printers to work with LTO optimized
>+executables.
>   
>   
> A new option -fcf-protection=[full|branch|return|none] is