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 <ve...@gmx.de> 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 <ve...@gmx.de> 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 <jvdeli...@charter.net> 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 > > > > > > > > > > > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de -- Andre Vehreschild * Email: vehre ad gmx dot de
