| Message ID | 20160127093944.GA28942@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
Patch: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01587.html On Wed, Jan 27, 2016 at 10:39:44AM +0100, Dominik Vogt wrote: > g++.dg/tls/thread_local-order2.C no longer fail with Glibc-2.18 or > newer since this commit: > > 2014-08-01 Zifei Tong <zifeitong@gmail.com> > > * libsupc++/atexit_thread.cc (HAVE___CXA_THREAD_ATEXIT_IMPL): Add > _GLIBCXX_ prefix to macro. > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@213504 138bc75d-0d04-0410-96 > > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02091.html > > So, is it time to remove the xfail from the test case? > > Ciao > > Dominik ^_^ ^_^ > > -- > > Dominik Vogt > IBM Germany > gcc/testsuite/ChangeLog > > * g++.dg/tls/thread_local-order2.C: Remove xfail. > >From 0b0abbd2e6d9d8b6857622065bdcbdde31b5ddb0 Mon Sep 17 00:00:00 2001 > From: Dominik Vogt <vogt@linux.vnet.ibm.com> > Date: Wed, 27 Jan 2016 09:54:07 +0100 > Subject: [PATCH] Remove xfail from thread_local-order2.C. > > This should work with Glibc-2.18 or newer. > --- > gcc/testsuite/g++.dg/tls/thread_local-order2.C | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/gcc/testsuite/g++.dg/tls/thread_local-order2.C b/gcc/testsuite/g++.dg/tls/thread_local-order2.C > index f8df917..d3351e6 100644 > --- a/gcc/testsuite/g++.dg/tls/thread_local-order2.C > +++ b/gcc/testsuite/g++.dg/tls/thread_local-order2.C > @@ -2,7 +2,6 @@ > // that isn't reverse order of construction. We need to move > // __cxa_thread_atexit into glibc to get this right. > > -// { dg-do run { xfail *-*-* } } > // { dg-require-effective-target c++11 } > // { dg-add-options tls } > // { dg-require-effective-target tls_runtime } > -- > 2.3.0 Ciao Dominik ^_^ ^_^
On Mon, Jun 20, 2016 at 02:41:21PM +0100, Dominik Vogt wrote: > Patch: > https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01587.html > > On Wed, Jan 27, 2016 at 10:39:44AM +0100, Dominik Vogt wrote: > > g++.dg/tls/thread_local-order2.C no longer fail with Glibc-2.18 or > > newer since this commit: > > > > 2014-08-01 Zifei Tong <zifeitong@gmail.com> > > > > * libsupc++/atexit_thread.cc (HAVE___CXA_THREAD_ATEXIT_IMPL): Add > > _GLIBCXX_ prefix to macro. > > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@213504 138bc75d-0d04-0410-96 > > > > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02091.html > > > > So, is it time to remove the xfail from the test case? > > gcc/testsuite/ChangeLog > > > > * g++.dg/tls/thread_local-order2.C: Remove xfail. > > > >From 0b0abbd2e6d9d8b6857622065bdcbdde31b5ddb0 Mon Sep 17 00:00:00 2001 > > From: Dominik Vogt <vogt@linux.vnet.ibm.com> > > Date: Wed, 27 Jan 2016 09:54:07 +0100 > > Subject: [PATCH] Remove xfail from thread_local-order2.C. > > > > This should work with Glibc-2.18 or newer. > > --- > > gcc/testsuite/g++.dg/tls/thread_local-order2.C | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/gcc/testsuite/g++.dg/tls/thread_local-order2.C b/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > index f8df917..d3351e6 100644 > > --- a/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > +++ b/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > @@ -2,7 +2,6 @@ > > // that isn't reverse order of construction. We need to move > > // __cxa_thread_atexit into glibc to get this right. > > > > -// { dg-do run { xfail *-*-* } } > > // { dg-require-effective-target c++11 } > > // { dg-add-options tls } > > // { dg-require-effective-target tls_runtime } > > -- > > 2.3.0 Ciao Dominik ^_^ ^_^
On Mon, Jun 20, 2016 at 02:41:21PM +0100, Dominik Vogt wrote: > Patch: > https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01587.html > > On Wed, Jan 27, 2016 at 10:39:44AM +0100, Dominik Vogt wrote: > > g++.dg/tls/thread_local-order2.C no longer fail with Glibc-2.18 or > > newer since this commit: > > > > 2014-08-01 Zifei Tong <zifeitong@gmail.com> > > > > * libsupc++/atexit_thread.cc (HAVE___CXA_THREAD_ATEXIT_IMPL): Add > > _GLIBCXX_ prefix to macro. > > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@213504 138bc75d-0d04-0410-96 > > > > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02091.html > > > > So, is it time to remove the xfail from the test case? > > gcc/testsuite/ChangeLog > > > > * g++.dg/tls/thread_local-order2.C: Remove xfail. > > > >From 0b0abbd2e6d9d8b6857622065bdcbdde31b5ddb0 Mon Sep 17 00:00:00 2001 > > From: Dominik Vogt <vogt@linux.vnet.ibm.com> > > Date: Wed, 27 Jan 2016 09:54:07 +0100 > > Subject: [PATCH] Remove xfail from thread_local-order2.C. > > > > This should work with Glibc-2.18 or newer. > > --- > > gcc/testsuite/g++.dg/tls/thread_local-order2.C | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/gcc/testsuite/g++.dg/tls/thread_local-order2.C b/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > index f8df917..d3351e6 100644 > > --- a/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > +++ b/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > @@ -2,7 +2,6 @@ > > // that isn't reverse order of construction. We need to move > > // __cxa_thread_atexit into glibc to get this right. > > > > -// { dg-do run { xfail *-*-* } } > > // { dg-require-effective-target c++11 } > > // { dg-add-options tls } > > // { dg-require-effective-target tls_runtime } > > -- > > 2.3.0 Ciao Dominik ^_^ ^_^
On Mon, Jun 20, 2016 at 02:41:21PM +0100, Dominik Vogt wrote: > Patch: > https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01587.html > > On Wed, Jan 27, 2016 at 10:39:44AM +0100, Dominik Vogt wrote: > > g++.dg/tls/thread_local-order2.C no longer fail with Glibc-2.18 or > > newer since this commit: > > > > 2014-08-01 Zifei Tong <zifeitong@gmail.com> > > > > * libsupc++/atexit_thread.cc (HAVE___CXA_THREAD_ATEXIT_IMPL): Add > > _GLIBCXX_ prefix to macro. > > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@213504 138bc75d-0d04-0410-96 > > > > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02091.html > > > > So, is it time to remove the xfail from the test case? > > gcc/testsuite/ChangeLog > > > > * g++.dg/tls/thread_local-order2.C: Remove xfail. > > > >From 0b0abbd2e6d9d8b6857622065bdcbdde31b5ddb0 Mon Sep 17 00:00:00 2001 > > From: Dominik Vogt <vogt@linux.vnet.ibm.com> > > Date: Wed, 27 Jan 2016 09:54:07 +0100 > > Subject: [PATCH] Remove xfail from thread_local-order2.C. > > > > This should work with Glibc-2.18 or newer. > > --- > > gcc/testsuite/g++.dg/tls/thread_local-order2.C | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/gcc/testsuite/g++.dg/tls/thread_local-order2.C b/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > index f8df917..d3351e6 100644 > > --- a/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > +++ b/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > @@ -2,7 +2,6 @@ > > // that isn't reverse order of construction. We need to move > > // __cxa_thread_atexit into glibc to get this right. > > > > -// { dg-do run { xfail *-*-* } } > > // { dg-require-effective-target c++11 } > > // { dg-add-options tls } > > // { dg-require-effective-target tls_runtime } > > -- > > 2.3.0 Ciao Dominik ^_^ ^_^
Pinging this for eight months now. :-/ On Mon, Jun 20, 2016 at 02:41:21PM +0100, Dominik Vogt wrote: > Patch: > https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01587.html > > On Wed, Jan 27, 2016 at 10:39:44AM +0100, Dominik Vogt wrote: > > g++.dg/tls/thread_local-order2.C no longer fail with Glibc-2.18 or > > newer since this commit: > > > > 2014-08-01 Zifei Tong <zifeitong@gmail.com> > > > > * libsupc++/atexit_thread.cc (HAVE___CXA_THREAD_ATEXIT_IMPL): Add > > _GLIBCXX_ prefix to macro. > > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@213504 138bc75d-0d04-0410-96 > > > > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02091.html > > > > So, is it time to remove the xfail from the test case? > > gcc/testsuite/ChangeLog > > > > * g++.dg/tls/thread_local-order2.C: Remove xfail. > > > >From 0b0abbd2e6d9d8b6857622065bdcbdde31b5ddb0 Mon Sep 17 00:00:00 2001 > > From: Dominik Vogt <vogt@linux.vnet.ibm.com> > > Date: Wed, 27 Jan 2016 09:54:07 +0100 > > Subject: [PATCH] Remove xfail from thread_local-order2.C. > > > > This should work with Glibc-2.18 or newer. > > --- > > gcc/testsuite/g++.dg/tls/thread_local-order2.C | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/gcc/testsuite/g++.dg/tls/thread_local-order2.C b/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > index f8df917..d3351e6 100644 > > --- a/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > +++ b/gcc/testsuite/g++.dg/tls/thread_local-order2.C > > @@ -2,7 +2,6 @@ > > // that isn't reverse order of construction. We need to move > > // __cxa_thread_atexit into glibc to get this right. > > > > -// { dg-do run { xfail *-*-* } } > > // { dg-require-effective-target c++11 } > > // { dg-add-options tls } > > // { dg-require-effective-target tls_runtime } > > -- > > 2.3.0 Ciao Dominik ^_^ ^_^
Copying the two guys listed as testsuite maintainers in gcc/MAINTAINERS may help; let me do that for you. That said, if this fails to fail, the patch might be considered obvious, not requiring a approval? Gerald On Mon, 6 Feb 2017, Dominik Vogt wrote: > Pinging this for eight months now. :-/ > > On Mon, Jun 20, 2016 at 02:41:21PM +0100, Dominik Vogt wrote: >> Patch: >> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01587.html >> >> On Wed, Jan 27, 2016 at 10:39:44AM +0100, Dominik Vogt wrote: >>> g++.dg/tls/thread_local-order2.C no longer fail with Glibc-2.18 or >>> newer since this commit: >>> >>> 2014-08-01 Zifei Tong <zifeitong@gmail.com> >>> >>> * libsupc++/atexit_thread.cc (HAVE___CXA_THREAD_ATEXIT_IMPL): Add >>> _GLIBCXX_ prefix to macro. >>> >>> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@213504 138bc75d-0d04-0410-96 >>> >>> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02091.html >>> >>> So, is it time to remove the xfail from the test case? >>> >>> gcc/testsuite/ChangeLog >>> >>> * g++.dg/tls/thread_local-order2.C: Remove xfail. >>> >>> From 0b0abbd2e6d9d8b6857622065bdcbdde31b5ddb0 Mon Sep 17 00:00:00 2001 >>> From: Dominik Vogt <vogt@linux.vnet.ibm.com> >>> Date: Wed, 27 Jan 2016 09:54:07 +0100 >>> Subject: [PATCH] Remove xfail from thread_local-order2.C. >>> >>> This should work with Glibc-2.18 or newer. >>> --- >>> gcc/testsuite/g++.dg/tls/thread_local-order2.C | 1 - >>> 1 file changed, 1 deletion(-) >>> >>> diff --git a/gcc/testsuite/g++.dg/tls/thread_local-order2.C b/gcc/testsuite/g++.dg/tls/thread_local-order2.C >>> index f8df917..d3351e6 100644 >>> --- a/gcc/testsuite/g++.dg/tls/thread_local-order2.C >>> +++ b/gcc/testsuite/g++.dg/tls/thread_local-order2.C >>> @@ -2,7 +2,6 @@ >>> // that isn't reverse order of construction. We need to move >>> // __cxa_thread_atexit into glibc to get this right. >>> >>> -// { dg-do run { xfail *-*-* } } >>> // { dg-require-effective-target c++11 } >>> // { dg-add-options tls } >>> // { dg-require-effective-target tls_runtime } >>> -- >>> 2.3.0
Hi Gerald, > Copying the two guys listed as testsuite maintainers in gcc/MAINTAINERS > may help; let me do that for you. > > That said, if this fails to fail, the patch might be considered obvious, > not requiring a approval? it's not: while it may XPASS with newer glibc versions, it still XFAILs e.g. on Solaris (and probably others). So unconditionally removing the xfail *-*-* trades an XPASS->PASS on some Linux versions against a XFAIL->FAIL elsewhere, which isn't acceptable. Rainer
On Mon, Feb 06, 2017 at 12:33:21PM +0100, Rainer Orth wrote: > > Copying the two guys listed as testsuite maintainers in gcc/MAINTAINERS > > may help; let me do that for you. > > > > That said, if this fails to fail, the patch might be considered obvious, > > not requiring a approval? > > it's not: while it may XPASS with newer glibc versions, it still XFAILs > e.g. on Solaris (and probably others). It's been so long that I cannot tell what the reference to glibc-2.18 means. I've only ever tested this on s390 and s390x, and the test may or may not PASS on other targets with glibc-2.18+. > So unconditionally removing the > xfail *-*-* trades an XPASS->PASS on some Linux versions against a > XFAIL->FAIL elsewhere, which isn't acceptable. Okay, so what would you suggest? // { dg-do run { xfail !s390*-*-* } } or // { dg-do run { xfail *-*-solaris } } or something else? We'll probably only get this list right by trial and error anyway. Ciao Dominik ^_^ ^_^
Hi Dominik, > On Mon, Feb 06, 2017 at 12:33:21PM +0100, Rainer Orth wrote: >> > Copying the two guys listed as testsuite maintainers in gcc/MAINTAINERS >> > may help; let me do that for you. >> > >> > That said, if this fails to fail, the patch might be considered obvious, >> > not requiring a approval? >> >> it's not: while it may XPASS with newer glibc versions, it still XFAILs >> e.g. on Solaris (and probably others). > > It's been so long that I cannot tell what the reference to > glibc-2.18 means. I've only ever tested this on s390 and s390x, > and the test may or may not PASS on other targets with > glibc-2.18+. > >> So unconditionally removing the >> xfail *-*-* trades an XPASS->PASS on some Linux versions against a >> XFAIL->FAIL elsewhere, which isn't acceptable. > > Okay, so what would you suggest? > > // { dg-do run { xfail !s390*-*-* } } > > or > > // { dg-do run { xfail *-*-solaris } } > > or something else? We'll probably only get this list right by > trial and error anyway. how about checking the gcc-testresults archives for XPASSes to get an idea? Rainer
On Mon, Feb 06, 2017 at 01:22:39PM +0100, Rainer Orth wrote: > Hi Dominik, > > > On Mon, Feb 06, 2017 at 12:33:21PM +0100, Rainer Orth wrote: > >> > Copying the two guys listed as testsuite maintainers in gcc/MAINTAINERS > >> > may help; let me do that for you. > >> > > >> > That said, if this fails to fail, the patch might be considered obvious, > >> > not requiring a approval? > >> > >> it's not: while it may XPASS with newer glibc versions, it still XFAILs > >> e.g. on Solaris (and probably others). > > > > It's been so long that I cannot tell what the reference to > > glibc-2.18 means. I've only ever tested this on s390 and s390x, > > and the test may or may not PASS on other targets with > > glibc-2.18+. > > > >> So unconditionally removing the > >> xfail *-*-* trades an XPASS->PASS on some Linux versions against a > >> XFAIL->FAIL elsewhere, which isn't acceptable. > > > > Okay, so what would you suggest? > > > > // { dg-do run { xfail !s390*-*-* } } > > > > or > > > > // { dg-do run { xfail *-*-solaris } } > > > > or something else? We'll probably only get this list right by > > trial and error anyway. > > how about checking the gcc-testresults archives for XPASSes to get an > idea? In the newest 300 matches on gcc-testresults, XPASS: g++.dg/tls/thread_local-order2.C -std=c++14 execution test appears for the following targets: s390 s390x i386-unknown-freebsd10.3 i686-pc-linux-gnu x86_64-pc-linux-gnu x86_64-apple-darwin16.4.0 x86_64-unknown-freebsd12.0 powerpc64le-unknown-linux-gnu powerpc-ibm-aix7.2.0.0 aarch64-unknown-linux-gnu aarch64-suse-linux-gnu hppa-unknown-linux-gnu armv6-unknown-freebsd12.0 target:arm-none-linux-gnueabi, host:i686-pc-linux-gnu target:m68k-unknown-linux-gnu; host:x86_64-suse-linux-gnu target:sh4-unknown-linux-gnu; host:i686-pc-linux-gnu Ciao Dominik ^_^ ^_^
On Feb 6, 2017, at 3:33 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > > Hi Gerald, > >> Copying the two guys listed as testsuite maintainers in gcc/MAINTAINERS >> may help; let me do that for you. >> >> That said, if this fails to fail, the patch might be considered obvious, >> not requiring a approval? > > it's not: while it may XPASS with newer glibc versions, it still XFAILs > e.g. on Solaris (and probably others). So unconditionally removing the > xfail *-*-* trades an XPASS->PASS on some Linux versions against a > XFAIL->FAIL elsewhere, which isn't acceptable. So, if it passes most everywhere, then I think the systems where it fails need to be identified and listed. Are there any solaris systems where it works? Systems like darwin and freebsd and aix seem to suggest that things should generally work; which means that the problem is likely just specific implementations of specific software. Anyone know of any other systems where it fails? I'll copy Jason to see if he recalls any systems where this might still fail. Anyway, I'd recommend just xfailing on solaris, and getting on with life. Other systems that fail, will trivially add themselves, or identify a way to xfail or otherwise mark as unsupported or add a new requirement if they prefer. Any objections?
On Mon, Feb 6, 2017 at 11:42 AM, Mike Stump <mikestump@comcast.net> wrote:
> I'll copy Jason to see if he recalls any systems where this might still fail.
Not particularly; I expected it to fail everywhere except recent
glibc, but apparently that isn't the case.
Jason
From 0b0abbd2e6d9d8b6857622065bdcbdde31b5ddb0 Mon Sep 17 00:00:00 2001 From: Dominik Vogt <vogt@linux.vnet.ibm.com> Date: Wed, 27 Jan 2016 09:54:07 +0100 Subject: [PATCH] Remove xfail from thread_local-order2.C. This should work with Glibc-2.18 or newer. --- gcc/testsuite/g++.dg/tls/thread_local-order2.C | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/testsuite/g++.dg/tls/thread_local-order2.C b/gcc/testsuite/g++.dg/tls/thread_local-order2.C index f8df917..d3351e6 100644 --- a/gcc/testsuite/g++.dg/tls/thread_local-order2.C +++ b/gcc/testsuite/g++.dg/tls/thread_local-order2.C @@ -2,7 +2,6 @@ // that isn't reverse order of construction. We need to move // __cxa_thread_atexit into glibc to get this right. -// { dg-do run { xfail *-*-* } } // { dg-require-effective-target c++11 } // { dg-add-options tls } // { dg-require-effective-target tls_runtime } -- 2.3.0
g++.dg/tls/thread_local-order2.C no longer fail with Glibc-2.18 or newer since this commit: 2014-08-01 Zifei Tong <zifeitong@gmail.com> * libsupc++/atexit_thread.cc (HAVE___CXA_THREAD_ATEXIT_IMPL): Add _GLIBCXX_ prefix to macro. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@213504 138bc75d-0d04-0410-96 https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02091.html So, is it time to remove the xfail from the test case? Ciao Dominik ^_^ ^_^