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

Reply via email to