Merge from gomp-4_5-branch to trunk

Hi!

On Fri, 6 Nov 2015 12:15:01 +0100, I wrote:
> On Thu, 5 Nov 2015 10:41:41 -0500, Nathan Sidwell <nathan@acm.org> wrote:
> > On 11/05/15 10:29, Jakub Jelinek wrote:
> > > I've merged the current state of gomp-4_5-branch into trunk, after
> > > bootstrapping/regtesting it on x86_64-linux and i686-linux.
> > >
> > > There are
> > > +FAIL: gfortran.dg/goacc/private-3.f95   -O  (test for excess errors)
> > > +FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-v-2.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors)
> > > +UNRESOLVED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-v-2.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 compilation failed to produce executable
> > > +FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-w-2.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors)
> > > +UNRESOLVED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-w-2.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 compilation failed to produce executable
> > > +FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/loop-red-v-2.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors)
> > > +UNRESOLVED: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/loop-red-v-2.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 compilation failed to produce executable
> > > +FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/loop-red-w-2.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors)
> > > +UNRESOLVED: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/loop-red-w-2.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 compilation failed to produce executable
> > > regressions, but I really don't know why OpenACC allows reductions against
> > > private variables, so either the testcases are wrong, or if OpenACC
> > > reduction can work against private vars (automatic vars inside of parallel
> > > too?), then perhaps it shouldn't set check_non_private for OpenACC
> > > reduction clauses or something similar.  Certainly, if there is private
> > > on the target region, returning 1 from omp_check_private is IMNSHO desirable
> > > (and required for OpenMP at least).
> > 
> > I'm working on porting patches for that, and I had noticed the check_non_private 
> > anomoly earlier today ...
> > 
> > I believe the c/c++ test cases are valid OpenACC, FWIW. (not checked the fortran 
> > one yet)
> 
> If that helps, this functionality ("private variable may also appear
> inside a reduction clause"), and the Fortran test case got added by Cesar
> in gomp-4_0-branch r215038,
> <http://news.gmane.org/find-root.php?message_id=%3C53E957F0.3090908%40codesourcery.com%3E>.
> 
> > Anyway, thanks for the heads-up, my ball.
> 
> Meanwhile, XFAILed in r229841:
> 
> commit 6e9b4ab07e26928819f04e39c20cb3cfceda9740
> Author: tschwinge <tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4>
> Date:   Fri Nov 6 11:11:34 2015 +0000
> 
>     XFAIL testcases regressed after r229814, "Merge from gomp-4_5-branch to trunk"
>     
>     	gcc/testsuite/
>     	* gfortran.dg/goacc/private-3.f95: XFAIL.
>     	libgomp/
>     	* testsuite/libgomp.oacc-c-c++-common/loop-red-v-2.c: XFAIL.
>     	* testsuite/libgomp.oacc-c-c++-common/loop-red-w-2.c: Likewise.

..., and another one, as reported in
<http://news.gmane.org/find-root.php?message_id=%3C563C0C29.6040209%40codesourcery.com%3E>,
in r229864:

commit 0b1ca60fccc0430eb41258a0822da206890e04c7
Author: tschwinge <tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Fri Nov 6 16:44:35 2015 +0000

    XFAIL testcases regressed after r229814, "Merge from gomp-4_5-branch to trunk"
    
    	gcc/testsuite/
    	* gfortran.dg/goacc/combined_loop.f90: XFAIL.
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@229864 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/testsuite/ChangeLog                           | 4 ++++
 gcc/testsuite/gfortran.dg/goacc/combined_loop.f90 | 3 +++
 2 files changed, 7 insertions(+)



Grüße
 Thomas