[PATCH] Merge from gomp-4_5-branch to trunk

[Nathan Sidwell]

On 11/05/15 10:29, Jakub Jelinek wrote:
> Hi!
>
> 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)

Anyway, thanks for the heads-up, my ball.

nathan