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

2015-11-08 Thread Thomas Schwinge 
Hi!

On Thu, 5 Nov 2015 16:29:36 +0100, 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.

Merged trunk r229814 into gomp-4_0-branch in r229947:

commit 7a6eb6b7cf9b72cf68a72b29d3bdc33e89dae58b
Merge: f782e15 9561765
Author: tschwinge 
Date:   Sun Nov 8 11:11:22 2015 +

svn merge -r 229809:229814 svn+ssh://gcc.gnu.org/svn/gcc/trunk


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@229947 
138bc75d-0d04-0410-961f-82ee72b054a4

> There are
> +FAIL: gfortran.dg/goacc/private-3.f95   -O  (test for excess errors)

[...]/gcc/testsuite/gfortran.dg/goacc/private-3.f95:19:0: Error: reduction 
variable 'k' is private in outer context

> +[more FAILs of the same kind]
> 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 [...]

These FAILs are not seen in the merged sources, and as Nathan noted in

and
,
they also disappear when applying the OpenACC firstprivate support patch
on trunk.

> This is much smaller merge than the one from 3 weeks ago

Confirmed.  ;-)


Grüße
 Thomas


signature.asc
Description: PGP signature

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

2015-11-06 Thread Martin Sebor 

On 11/05/2015 09:08 PM, David Edelsohn wrote:

Sorry for the incorrect blame.  I thought the failure was due to GOMP
changes, but it appears to be due to the placement new size changes.
I am re-testing after Martin's fix.

By the way, Martin, the ChangeLog entry is wrong


I've fixed the ChangeLog.

With Jason's help, I've also figured out why I missed the libstdc++
boostrap breakage. I've been assuming that make bootstrap invoked
after a change to the compiler rebuilds libstdc++ and any other
libraries. That apparently isn't the case. I will need to adjust
my workflow to avoid this problem in the future. If there is a page
on the Wiki or somewhere with best practices or recommended steps
that someone knows about, I'd be grateful for a pointer.

Again, sorry for the breakage.

Martin



2015-11-05  Martin Sebor  

 PR c++/67942
 * invoke.texi (-Wplacement-new): Document new option.
 * gcc/testsuite/g++.dg/warn/Wplacement-new-size.C: New test.

The invoke.texi change should list doc/invoke.texi and the testsuite
change should go in testsuite/ChangeLog.

Thanks, David

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

2015-11-06 Thread Thomas Schwinge 
Hi!

On Fri, 6 Nov 2015 12:15:01 +0100, I wrote:
> On Thu, 5 Nov 2015 10:41:41 -0500, Nathan Sidwell  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,
> .
> 
> > Anyway, thanks for the heads-up, my ball.
> 
> Meanwhile, XFAILed in r229841:
> 
> commit 6e9b4ab07e26928819f04e39c20cb3cfceda9740
> Author: tschwinge 
> Date:   Fri Nov 6 11:11:34 2015 +
> 
> 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
,
in r229864:

commit 0b1ca60fccc0430eb41258a0822da206890e04c7
Author: tschwinge 
Date:   Fri Nov 6 16:44:35 2015 +

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(+)

diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index 1fe39a4..ad9ec92 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2015-11-06  Thomas Schwinge  
+
+   * gfortran.dg/goacc/combined_loop.f90: XFAIL.
+
 2015-11-07  Jan Hubicka  
 
PR ipa/68057
diff --git gcc/testsuite/gfortran.dg/goacc/combined_loop.f90 
gcc/testsuite/gfortran.dg/goacc/combined_loop.f90
index abb10f9..e0ea87a 100644
--- gcc/testsuite/gfortran.dg/goacc/combined_loop.f90
+++ gcc/testsuite/gfortran.dg/goacc/combined_loop.f90
@@ -1,4 +1,7 @@
 ! { dg-do compile } 
+! 

+! { dg-xfail-if "TODO" { *-*-* } }
+
 !
 ! PR fortran/64726
 !


Grüße
 Thomas


signature.asc
Description: PGP signature

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

2015-11-06 Thread Thomas Schwinge 
Hi!

On Thu, 5 Nov 2015 10:41:41 -0500, Nathan Sidwell  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,
.

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

Meanwhile, XFAILed in r229841:

commit 6e9b4ab07e26928819f04e39c20cb3cfceda9740
Author: tschwinge 
Date:   Fri Nov 6 11:11:34 2015 +

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.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@229841 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/testsuite/ChangeLog|4 
 gcc/testsuite/gfortran.dg/goacc/private-3.f95  |3 ++-
 libgomp/ChangeLog  |5 +
 libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-v-2.c |2 ++
 libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-w-2.c |2 ++
 5 files changed, 15 insertions(+), 1 deletion(-)

diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index af9bd72..b0e78e9 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2015-11-06  Thomas Schwinge  
+
+   * gfortran.dg/goacc/private-3.f95: XFAIL.
+
 2015-11-06  Joost VandeVondele  
 
PR middle-end/53852
diff --git gcc/testsuite/gfortran.dg/goacc/private-3.f95 
gcc/testsuite/gfortran.dg/goacc/private-3.f95
index aa12a56..af7d683 100644
--- gcc/testsuite/gfortran.dg/goacc/private-3.f95
+++ gcc/testsuite/gfortran.dg/goacc/private-3.f95
@@ -1,4 +1,6 @@
 ! { dg-do compile }
+! 

+! { dg-xfail-if "TODO" { *-*-* } }
 
 ! test for private variables in a reduction clause
 
@@ -7,7 +9,6 @@ program test
   integer, parameter :: n = 100
   integer :: i, k
 
-!  FIXME: This causes an ICE in the gimplifier.
 !  !$acc parallel private (k) reduction (+:k)
 !  do i = 1, n
 ! k = k + 1
diff --git libgomp/ChangeLog libgomp/ChangeLog
index 26377b6..ab2a25a 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,3 +1,8 @@
+2015-11-06  Thomas Schwinge  
+
+   * testsuite/libgomp.oacc-c-c++-common/loop-red-v-2.c: XFAIL.
+   * testsuite/libgomp.oacc-c-c++-common/loop-red-w-2.c: Likewise.
+
 2015-11-05  Jakub Jelinek  
Ilya Verbin  
 
diff --git libgomp/testsuite/libgomp.oacc-c-c++-common/loop-

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

2015-11-05 Thread David Edelsohn 
Sorry for the incorrect blame.  I thought the failure was due to GOMP
changes, but it appears to be due to the placement new size changes.
I am re-testing after Martin's fix.

By the way, Martin, the ChangeLog entry is wrong

2015-11-05  Martin Sebor  

PR c++/67942
* invoke.texi (-Wplacement-new): Document new option.
* gcc/testsuite/g++.dg/warn/Wplacement-new-size.C: New test.

The invoke.texi change should list doc/invoke.texi and the testsuite
change should go in testsuite/ChangeLog.

Thanks, David

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

2015-11-05 Thread 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