Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier
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 > > > > > > > > > > > > > -- > An
Re: [committed] fix a couple of typos in manual
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
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
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
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
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
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 (&lhs_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 (&lhs_expr->ts); + tmp = build_fold_indirect_ref_loc (input_location, lhs_se.expr); + gfc_add_modify (&lhs_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 (&block, lhs_se.expr, &ar2); + *ar = ar2; + } } - lhs_se.want_pointer = 1; - gfc_conv_expr_descriptor (&lhs_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 (&lhs_expr->ts); - tmp = build_fold_indirect_ref_loc (input_location, lhs_se.expr); - gfc_add_modify (&lhs_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 (&block, lhs_se.expr, &ar2); - *ar = ar2; + /* Special casing for arr1 ([...]) = arr2[...], i.e. caf_get to + index
New Swedish PO file for 'gcc' (version 8.1-b20180401)
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.