* Re: OpenACC 'kernels' testsuite failures @ 2020-11-15 20:47 David Edelsohn 2020-11-16 14:16 ` Thomas Schwinge 0 siblings, 1 reply; 12+ messages in thread From: David Edelsohn @ 2020-11-15 20:47 UTC (permalink / raw) To: Thomas Schwinge; +Cc: GCC Patches Thomas, I am seeing a number of new failures on AIX related to the OpenACC kernels patches. c-c++-common/goacc/kernels-decompose-1.c c-c++-common/goacc/kernels-decompose-2.c gfortran.dg/goacc/kernels-decompose-1.f95 gfortran.dg/goacc/kernels-decompose-2.f95 libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c libgomp.oacc-fortran/pr94358-1.f90 Looking at the testsuite logs I see: fatal error: GCC is not configured to support amdgcn-amdhsa as offload target I don't know why this is different from the other OpenACC tests. How should these tests be skipped or adjusted to not fail on other systems? Thanks, David ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-15 20:47 OpenACC 'kernels' testsuite failures David Edelsohn @ 2020-11-16 14:16 ` Thomas Schwinge 2020-11-16 16:32 ` David Edelsohn 0 siblings, 1 reply; 12+ messages in thread From: Thomas Schwinge @ 2020-11-16 14:16 UTC (permalink / raw) To: David Edelsohn; +Cc: GCC Patches Hi David! Thanks for reporting. On 2020-11-15T15:47:15-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > I am seeing a number of new failures on AIX related to the OpenACC > kernels patches. > > c-c++-common/goacc/kernels-decompose-1.c > c-c++-common/goacc/kernels-decompose-2.c > gfortran.dg/goacc/kernels-decompose-1.f95 > gfortran.dg/goacc/kernels-decompose-2.f95 > libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c > libgomp.oacc-fortran/pr94358-1.f90 I suppose what you're asking about is what appears in <gcc-testresults@gcc.gnu.org> reports as: ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " UNRESOLVED: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " Etc. However, per the reports posted there, these really only (!) appear to fail for your "Native configuration is powerpc-ibm-aix7.2.3.0" testing, strange. Which versions of DejaGnu and Tcl are used? On <https://cfarm.tetaneutral.net/machines/list/> I see there are AIX systems gcc111, gcc119 -- maybe I'll have luck reproducing the issue there. Admittedly, using Tcl code inside DejaGnu directives is not most common, but it does make sense conceptually (at least to me), and reportedly does work with a large number of DejaGnu/Tcl versions combinations. > Looking at the testsuite logs I see: > > fatal error: GCC is not configured to support amdgcn-amdhsa as offload target That one's not actually related to the new OpenACC 'kernels' testcases: it's just the testsuite harness checking whether GCN offloading is configured. (See <https://gcc.gnu.org/PR88920> "GCC is not configured to support amdgcn-unknown-amdhsa as offload target"; this should one appear once per testsuite.) > I don't know why this is different from the other OpenACC tests. It's not. At least not intentionally. > How > should these tests be skipped or adjusted to not fail on other > systems? They are expected to work fine on all systems; they're not specific to actual code offloading. So if something FAILs, we shall resolve it. Grüße Thomas ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-16 14:16 ` Thomas Schwinge @ 2020-11-16 16:32 ` David Edelsohn 2020-11-16 16:46 ` Thomas Schwinge 0 siblings, 1 reply; 12+ messages in thread From: David Edelsohn @ 2020-11-16 16:32 UTC (permalink / raw) To: Thomas Schwinge; +Cc: GCC Patches On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge <thomas@codesourcery.com> wrote: > > Hi David! > > Thanks for reporting. > > On 2020-11-15T15:47:15-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > > I am seeing a number of new failures on AIX related to the OpenACC > > kernels patches. > > > > c-c++-common/goacc/kernels-decompose-1.c > > c-c++-common/goacc/kernels-decompose-2.c > > gfortran.dg/goacc/kernels-decompose-1.f95 > > gfortran.dg/goacc/kernels-decompose-2.f95 > > libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c > > libgomp.oacc-fortran/pr94358-1.f90 > > I suppose what you're asking about is what appears in > <gcc-testresults@gcc.gnu.org> reports as: > > ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " > UNRESOLVED: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " > > Etc. > > However, per the reports posted there, these really only (!) appear to > fail for your "Native configuration is powerpc-ibm-aix7.2.3.0" testing, > strange. Which versions of DejaGnu and Tcl are used? For my internal tester DejaGNU reports the following: Expect version is 5.42.1 Tcl version is 8.4 Framework version is 1.5.3 > > On <https://cfarm.tetaneutral.net/machines/list/> I see there are AIX > systems gcc111, gcc119 -- maybe I'll have luck reproducing the issue > there. > > Admittedly, using Tcl code inside DejaGnu directives is not most common, > but it does make sense conceptually (at least to me), and reportedly does > work with a large number of DejaGnu/Tcl versions combinations. > > > Looking at the testsuite logs I see: > > > > fatal error: GCC is not configured to support amdgcn-amdhsa as offload target > > That one's not actually related to the new OpenACC 'kernels' testcases: > it's just the testsuite harness checking whether GCN offloading is > configured. (See <https://gcc.gnu.org/PR88920> "GCC is not configured to > support amdgcn-unknown-amdhsa as offload target"; this should one appear > once per testsuite.) > > > I don't know why this is different from the other OpenACC tests. > > It's not. At least not intentionally. I don't see any obvious difference in the style of the additional options for the kernels testcases versus others, although it specifically is using an option for that test. I only see the "GCC is not configured ... amdhsa" for those tests. > > > How > > should these tests be skipped or adjusted to not fail on other > > systems? > > They are expected to work fine on all systems; they're not specific to > actual code offloading. So if something FAILs, we shall resolve it. Thanks, David ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-16 16:32 ` David Edelsohn @ 2020-11-16 16:46 ` Thomas Schwinge 2020-11-17 15:03 ` David Edelsohn 0 siblings, 1 reply; 12+ messages in thread From: Thomas Schwinge @ 2020-11-16 16:46 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 4565 bytes --] Hi David! While you were writing your email, I've also been busy: On 2020-11-16T11:32:46-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge <thomas@codesourcery.com> wrote: >> On 2020-11-15T15:47:15-0500, David Edelsohn <dje.gcc@gmail.com> wrote: >> > I am seeing a number of new failures on AIX related to the OpenACC >> > kernels patches. >> > >> > c-c++-common/goacc/kernels-decompose-1.c >> > c-c++-common/goacc/kernels-decompose-2.c >> > gfortran.dg/goacc/kernels-decompose-1.f95 >> > gfortran.dg/goacc/kernels-decompose-2.f95 >> > libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c >> > libgomp.oacc-fortran/pr94358-1.f90 >> >> I suppose what you're asking about is what appears in >> <gcc-testresults@gcc.gnu.org> reports as: >> >> ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " >> UNRESOLVED: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " >> >> Etc. In the mean time, I did remember that weeks ago, I had noticed this following "detail": on <https://www.tcl.tk/man/tcl8.5/TclCmd/incr.htm> we read that "Starting with the Tcl 8.5 release, the variable 'varName' passed to 'incr' may be unset, and in that case, it will be set to [...]". Tcl 8.5 has been released in 2007. Per 'gcc/doc/install.texi' we require: @item DejaGnu 1.4.4 @itemx Expect @itemx Tcl Necessary to run the GCC testsuite; [...] DejaGnu has been released in 2004 (so cannot have required Tcl 8.5 released in 2007). >> However, per the reports posted there, these really only (!) appear to >> fail for your "Native configuration is powerpc-ibm-aix7.2.3.0" testing, >> strange. Which versions of DejaGnu and Tcl are used? > > For my internal tester DejaGNU reports the following: > > Expect version is 5.42.1 > Tcl version is 8.4 > Framework version is 1.5.3 There we go: you're on Tcl 8.4. ;-D >> On <https://cfarm.tetaneutral.net/machines/list/> I see there are AIX >> systems gcc111, gcc119 -- maybe I'll have luck reproducing the issue >> there. On these, we've got: tschwinge@gcc111:[/home/tschwinge]/opt/freeware/bin/runtest --version WARNING: Couldn't find the global config file. Expect version is 5.45.4 Tcl version is 8.6 Framework version is 1.4.4 tschwinge@gcc119:[/home/tschwinge]/opt/freeware/bin/runtest --version WARNING: Couldn't find the global config file. Expect version is 5.44.1.15 Tcl version is 8.5 Framework version is 1.5.3 ..., so can't (easily) be used to reproduce the issue. (... but it wouldn't be specific to AIX, anyway.) Before I spend time on building/verifying with Tcl 8.4: are you able to give the attached patch "[testsuite] Avoid Tcl 8.5-specific behavior" a try? Grüße Thomas >> Admittedly, using Tcl code inside DejaGnu directives is not most common, >> but it does make sense conceptually (at least to me), and reportedly does >> work with a large number of DejaGnu/Tcl versions combinations. >> >> > Looking at the testsuite logs I see: >> > >> > fatal error: GCC is not configured to support amdgcn-amdhsa as offload target >> >> That one's not actually related to the new OpenACC 'kernels' testcases: >> it's just the testsuite harness checking whether GCN offloading is >> configured. (See <https://gcc.gnu.org/PR88920> "GCC is not configured to >> support amdgcn-unknown-amdhsa as offload target"; this should one appear >> once per testsuite.) >> >> > I don't know why this is different from the other OpenACC tests. >> >> It's not. At least not intentionally. > > I don't see any obvious difference in the style of the additional > options for the kernels testcases versus others, although it > specifically is using an option for that test. I only see the "GCC is > not configured ... amdhsa" for those tests. > >> >> > How >> > should these tests be skipped or adjusted to not fail on other >> > systems? >> >> They are expected to work fine on all systems; they're not specific to >> actual code offloading. So if something FAILs, we shall resolve it. > > Thanks, David ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-testsuite-Avoid-Tcl-8.5-specific-behavior.patch --] [-- Type: text/x-diff, Size: 6025 bytes --] From cde6156007fbf6376851d2343d8870a98998773d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge <thomas@codesourcery.com> Date: Mon, 16 Nov 2020 17:37:06 +0100 Subject: [PATCH] [testsuite] Avoid Tcl 8.5-specific behavior --- gcc/testsuite/c-c++-common/goacc/kernels-decompose-1.c | 8 ++++++++ gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c | 8 ++++++++ gcc/testsuite/gfortran.dg/goacc/kernels-decompose-1.f95 | 8 ++++++++ gcc/testsuite/gfortran.dg/goacc/kernels-decompose-2.f95 | 8 ++++++++ .../libgomp.oacc-c-c++-common/kernels-decompose-1.c | 8 ++++++++ libgomp/testsuite/libgomp.oacc-fortran/pr94358-1.f90 | 8 ++++++++ 6 files changed, 48 insertions(+) diff --git a/gcc/testsuite/c-c++-common/goacc/kernels-decompose-1.c b/gcc/testsuite/c-c++-common/goacc/kernels-decompose-1.c index 92db33273eb..e906443cceb 100644 --- a/gcc/testsuite/c-c++-common/goacc/kernels-decompose-1.c +++ b/gcc/testsuite/c-c++-common/goacc/kernels-decompose-1.c @@ -7,6 +7,14 @@ /* See also '../../gfortran.dg/goacc/kernels-decompose-1.f95'. */ +/* It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' + passed to 'incr' may be unset, and in that case, it will be set to [...]", + so to maintain compatibility with earlier Tcl releases, we manually + initialize counter variables: + { dg-line l_dummy[variable c_loop_i 0] } + { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid + "WARNING: dg-line var l_dummy defined, but not used". */ + #define N 1024 unsigned int a[N]; diff --git a/gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c b/gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c index ec6c4af92aa..ec0f75c4a61 100644 --- a/gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c +++ b/gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c @@ -6,6 +6,14 @@ /* See also '../../gfortran.dg/goacc/kernels-decompose-2.f95'. */ +/* It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' + passed to 'incr' may be unset, and in that case, it will be set to [...]", + so to maintain compatibility with earlier Tcl releases, we manually + initialize counter variables: + { dg-line l_dummy[variable c_loop_i 0 c_loop_j 0 c_loop_k 0 c_part 0] } + { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid + "WARNING: dg-line var l_dummy defined, but not used". */ + #pragma acc routine gang extern int f_g (int); diff --git a/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-1.f95 b/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-1.f95 index 95a78623ebf..7e513f84083 100644 --- a/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-1.f95 +++ b/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-1.f95 @@ -7,6 +7,14 @@ ! See also '../../c-c++-common/goacc/kernels-decompose-1.c'. +! It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' +! passed to 'incr' may be unset, and in that case, it will be set to [...]", +! so to maintain compatibility with earlier Tcl releases, we manually +! initialize counter variables: +! { dg-line l_dummy[variable c_loop_i 0] } +! { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid +! "WARNING: dg-line var l_dummy defined, but not used". + program main implicit none integer, parameter :: N = 1024 diff --git a/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-2.f95 b/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-2.f95 index 58d687d4a0c..22f65e5c694 100644 --- a/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-2.f95 +++ b/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-2.f95 @@ -6,6 +6,14 @@ ! See also '../../c-c++-common/goacc/kernels-decompose-2.c'. +! It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' +! passed to 'incr' may be unset, and in that case, it will be set to [...]", +! so to maintain compatibility with earlier Tcl releases, we manually +! initialize counter variables: +! { dg-line l_dummy[variable c_loop_i 0 c_loop_j 0 c_loop_k 0 c_part 0] } +! { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid +! "WARNING: dg-line var l_dummy defined, but not used". + program main implicit none diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c index fa8ae6c79cd..e76e4099f3a 100644 --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c @@ -3,6 +3,14 @@ /* { dg-additional-options "-fopt-info-omp-all" } */ /* { dg-additional-options "-fopenacc-kernels=decompose" } */ +/* It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' + passed to 'incr' may be unset, and in that case, it will be set to [...]", + so to maintain compatibility with earlier Tcl releases, we manually + initialize counter variables: + { dg-line l_dummy[variable c_loop_i 0] } + { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid + "WARNING: dg-line var l_dummy defined, but not used". */ + #undef NDEBUG #include <assert.h> diff --git a/libgomp/testsuite/libgomp.oacc-fortran/pr94358-1.f90 b/libgomp/testsuite/libgomp.oacc-fortran/pr94358-1.f90 index 82d8351f0e3..99a70418a4d 100644 --- a/libgomp/testsuite/libgomp.oacc-fortran/pr94358-1.f90 +++ b/libgomp/testsuite/libgomp.oacc-fortran/pr94358-1.f90 @@ -2,6 +2,14 @@ ! { dg-additional-options "-fopt-info-omp-all" } ! { dg-additional-options "-fopenacc-kernels=decompose" } +! It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' +! passed to 'incr' may be unset, and in that case, it will be set to [...]", +! so to maintain compatibility with earlier Tcl releases, we manually +! initialize counter variables: +! { dg-line l_dummy[variable c_loop_i 0] } +! { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid +! "WARNING: dg-line var l_dummy defined, but not used". + subroutine kernel(lo, hi, a, b, c) implicit none integer :: lo, hi, i -- 2.17.1 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-16 16:46 ` Thomas Schwinge @ 2020-11-17 15:03 ` David Edelsohn 2020-11-18 1:18 ` David Edelsohn 0 siblings, 1 reply; 12+ messages in thread From: David Edelsohn @ 2020-11-17 15:03 UTC (permalink / raw) To: Thomas Schwinge; +Cc: GCC Patches Hi, Thomas The standard version of Tcl installed on AIX currently is Tcl 8.4. I'll see if I can have a newer version on the side. The patch resolves the "no such variable" error message. (Great! Thanks!) I now see: during GIMPLE pass: omplower as an Excess error. Any idea where that comes from and why it doesn't appear on other targets? Does that need to be captured and ignored? Thanks, David On Mon, Nov 16, 2020 at 11:46 AM Thomas Schwinge <thomas@codesourcery.com> wrote: > > Hi David! > > While you were writing your email, I've also been busy: > > On 2020-11-16T11:32:46-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge <thomas@codesourcery.com> wrote: > >> On 2020-11-15T15:47:15-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > >> > I am seeing a number of new failures on AIX related to the OpenACC > >> > kernels patches. > >> > > >> > c-c++-common/goacc/kernels-decompose-1.c > >> > c-c++-common/goacc/kernels-decompose-2.c > >> > gfortran.dg/goacc/kernels-decompose-1.f95 > >> > gfortran.dg/goacc/kernels-decompose-2.f95 > >> > libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c > >> > libgomp.oacc-fortran/pr94358-1.f90 > >> > >> I suppose what you're asking about is what appears in > >> <gcc-testresults@gcc.gnu.org> reports as: > >> > >> ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " > >> UNRESOLVED: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " > >> > >> Etc. > > In the mean time, I did remember that weeks ago, I had noticed this > following "detail": on <https://www.tcl.tk/man/tcl8.5/TclCmd/incr.htm> we > read that "Starting with the Tcl 8.5 release, the variable 'varName' > passed to 'incr' may be unset, and in that case, it will be set to > [...]". Tcl 8.5 has been released in 2007. > > Per 'gcc/doc/install.texi' we require: > > @item DejaGnu 1.4.4 > @itemx Expect > @itemx Tcl > > Necessary to run the GCC testsuite; [...] > > DejaGnu has been released in 2004 (so cannot have required Tcl 8.5 > released in 2007). > > >> However, per the reports posted there, these really only (!) appear to > >> fail for your "Native configuration is powerpc-ibm-aix7.2.3.0" testing, > >> strange. Which versions of DejaGnu and Tcl are used? > > > > For my internal tester DejaGNU reports the following: > > > > Expect version is 5.42.1 > > Tcl version is 8.4 > > Framework version is 1.5.3 > > There we go: you're on Tcl 8.4. ;-D > > >> On <https://cfarm.tetaneutral.net/machines/list/> I see there are AIX > >> systems gcc111, gcc119 -- maybe I'll have luck reproducing the issue > >> there. > > On these, we've got: > > tschwinge@gcc111:[/home/tschwinge]/opt/freeware/bin/runtest --version > WARNING: Couldn't find the global config file. > Expect version is 5.45.4 > Tcl version is 8.6 > Framework version is 1.4.4 > > tschwinge@gcc119:[/home/tschwinge]/opt/freeware/bin/runtest --version > WARNING: Couldn't find the global config file. > Expect version is 5.44.1.15 > Tcl version is 8.5 > Framework version is 1.5.3 > > ..., so can't (easily) be used to reproduce the issue. (... but it > wouldn't be specific to AIX, anyway.) > > Before I spend time on building/verifying with Tcl 8.4: are you able to > give the attached patch "[testsuite] Avoid Tcl 8.5-specific behavior" a > try? > > > Grüße > Thomas > > > >> Admittedly, using Tcl code inside DejaGnu directives is not most common, > >> but it does make sense conceptually (at least to me), and reportedly does > >> work with a large number of DejaGnu/Tcl versions combinations. > >> > >> > Looking at the testsuite logs I see: > >> > > >> > fatal error: GCC is not configured to support amdgcn-amdhsa as offload target > >> > >> That one's not actually related to the new OpenACC 'kernels' testcases: > >> it's just the testsuite harness checking whether GCN offloading is > >> configured. (See <https://gcc.gnu.org/PR88920> "GCC is not configured to > >> support amdgcn-unknown-amdhsa as offload target"; this should one appear > >> once per testsuite.) > >> > >> > I don't know why this is different from the other OpenACC tests. > >> > >> It's not. At least not intentionally. > > > > I don't see any obvious difference in the style of the additional > > options for the kernels testcases versus others, although it > > specifically is using an option for that test. I only see the "GCC is > > not configured ... amdhsa" for those tests. > > > >> > >> > How > >> > should these tests be skipped or adjusted to not fail on other > >> > systems? > >> > >> They are expected to work fine on all systems; they're not specific to > >> actual code offloading. So if something FAILs, we shall resolve it. > > > > Thanks, David > > > ----------------- > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-17 15:03 ` David Edelsohn @ 2020-11-18 1:18 ` David Edelsohn 2020-11-21 15:50 ` David Edelsohn 0 siblings, 1 reply; 12+ messages in thread From: David Edelsohn @ 2020-11-18 1:18 UTC (permalink / raw) To: Thomas Schwinge; +Cc: GCC Patches Hi, Thomas The patch resolves the "no such variable" error message, but I see "during GIMPLE pass: omplower" excess error message. I installed Tcl 8.6 with Expect 5.45. This removes the "no such variable" error messages for C and C++ test cases, but they still occur for Fortran. I guess that the patch is necessary because there seems to be something else still behaving differently on AIX. Any insights? Thanks, David On Tue, Nov 17, 2020 at 10:03 AM David Edelsohn <dje.gcc@gmail.com> wrote: > > Hi, Thomas > > The standard version of Tcl installed on AIX currently is Tcl 8.4. > I'll see if I can have a newer version on the side. > > The patch resolves the "no such variable" error message. (Great! > Thanks!) I now see: > > during GIMPLE pass: omplower > > as an Excess error. Any idea where that comes from and why it doesn't > appear on other targets? Does that need to be captured and ignored? > > Thanks, David > > On Mon, Nov 16, 2020 at 11:46 AM Thomas Schwinge > <thomas@codesourcery.com> wrote: > > > > Hi David! > > > > While you were writing your email, I've also been busy: > > > > On 2020-11-16T11:32:46-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > > > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge <thomas@codesourcery.com> wrote: > > >> On 2020-11-15T15:47:15-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > > >> > I am seeing a number of new failures on AIX related to the OpenACC > > >> > kernels patches. > > >> > > > >> > c-c++-common/goacc/kernels-decompose-1.c > > >> > c-c++-common/goacc/kernels-decompose-2.c > > >> > gfortran.dg/goacc/kernels-decompose-1.f95 > > >> > gfortran.dg/goacc/kernels-decompose-2.f95 > > >> > libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c > > >> > libgomp.oacc-fortran/pr94358-1.f90 > > >> > > >> I suppose what you're asking about is what appears in > > >> <gcc-testresults@gcc.gnu.org> reports as: > > >> > > >> ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " > > >> UNRESOLVED: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " > > >> > > >> Etc. > > > > In the mean time, I did remember that weeks ago, I had noticed this > > following "detail": on <https://www.tcl.tk/man/tcl8.5/TclCmd/incr.htm> we > > read that "Starting with the Tcl 8.5 release, the variable 'varName' > > passed to 'incr' may be unset, and in that case, it will be set to > > [...]". Tcl 8.5 has been released in 2007. > > > > Per 'gcc/doc/install.texi' we require: > > > > @item DejaGnu 1.4.4 > > @itemx Expect > > @itemx Tcl > > > > Necessary to run the GCC testsuite; [...] > > > > DejaGnu has been released in 2004 (so cannot have required Tcl 8.5 > > released in 2007). > > > > >> However, per the reports posted there, these really only (!) appear to > > >> fail for your "Native configuration is powerpc-ibm-aix7.2.3.0" testing, > > >> strange. Which versions of DejaGnu and Tcl are used? > > > > > > For my internal tester DejaGNU reports the following: > > > > > > Expect version is 5.42.1 > > > Tcl version is 8.4 > > > Framework version is 1.5.3 > > > > There we go: you're on Tcl 8.4. ;-D > > > > >> On <https://cfarm.tetaneutral.net/machines/list/> I see there are AIX > > >> systems gcc111, gcc119 -- maybe I'll have luck reproducing the issue > > >> there. > > > > On these, we've got: > > > > tschwinge@gcc111:[/home/tschwinge]/opt/freeware/bin/runtest --version > > WARNING: Couldn't find the global config file. > > Expect version is 5.45.4 > > Tcl version is 8.6 > > Framework version is 1.4.4 > > > > tschwinge@gcc119:[/home/tschwinge]/opt/freeware/bin/runtest --version > > WARNING: Couldn't find the global config file. > > Expect version is 5.44.1.15 > > Tcl version is 8.5 > > Framework version is 1.5.3 > > > > ..., so can't (easily) be used to reproduce the issue. (... but it > > wouldn't be specific to AIX, anyway.) > > > > Before I spend time on building/verifying with Tcl 8.4: are you able to > > give the attached patch "[testsuite] Avoid Tcl 8.5-specific behavior" a > > try? > > > > > > Grüße > > Thomas > > > > > > >> Admittedly, using Tcl code inside DejaGnu directives is not most common, > > >> but it does make sense conceptually (at least to me), and reportedly does > > >> work with a large number of DejaGnu/Tcl versions combinations. > > >> > > >> > Looking at the testsuite logs I see: > > >> > > > >> > fatal error: GCC is not configured to support amdgcn-amdhsa as offload target > > >> > > >> That one's not actually related to the new OpenACC 'kernels' testcases: > > >> it's just the testsuite harness checking whether GCN offloading is > > >> configured. (See <https://gcc.gnu.org/PR88920> "GCC is not configured to > > >> support amdgcn-unknown-amdhsa as offload target"; this should one appear > > >> once per testsuite.) > > >> > > >> > I don't know why this is different from the other OpenACC tests. > > >> > > >> It's not. At least not intentionally. > > > > > > I don't see any obvious difference in the style of the additional > > > options for the kernels testcases versus others, although it > > > specifically is using an option for that test. I only see the "GCC is > > > not configured ... amdhsa" for those tests. > > > > > >> > > >> > How > > >> > should these tests be skipped or adjusted to not fail on other > > >> > systems? > > >> > > >> They are expected to work fine on all systems; they're not specific to > > >> actual code offloading. So if something FAILs, we shall resolve it. > > > > > > Thanks, David > > > > > > ----------------- > > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany > > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-18 1:18 ` David Edelsohn @ 2020-11-21 15:50 ` David Edelsohn 2020-11-24 10:19 ` Thomas Schwinge 0 siblings, 1 reply; 12+ messages in thread From: David Edelsohn @ 2020-11-21 15:50 UTC (permalink / raw) To: Thomas Schwinge; +Cc: GCC Patches Hi, Thomas I see "during GIMPLE pass: omplower" message for kernels-decompose-ice-2.c. kernels-decompose-ice-1.c explicitly prunes that output, but kernels-decompose-ice-2.c does not. Is there a reason that the second testcase does not prune that output or can we add it? Thanks, David On Tue, Nov 17, 2020 at 8:18 PM David Edelsohn <dje.gcc@gmail.com> wrote: > > Hi, Thomas > > The patch resolves the "no such variable" error message, but I see > > "during GIMPLE pass: omplower" > > excess error message. > > I installed Tcl 8.6 with Expect 5.45. This removes the "no such > variable" error messages for C and C++ test cases, but they still > occur for Fortran. > > I guess that the patch is necessary because there seems to be > something else still behaving differently on AIX. > > Any insights? > > Thanks, David > > On Tue, Nov 17, 2020 at 10:03 AM David Edelsohn <dje.gcc@gmail.com> wrote: > > > > Hi, Thomas > > > > The standard version of Tcl installed on AIX currently is Tcl 8.4. > > I'll see if I can have a newer version on the side. > > > > The patch resolves the "no such variable" error message. (Great! > > Thanks!) I now see: > > > > during GIMPLE pass: omplower > > > > as an Excess error. Any idea where that comes from and why it doesn't > > appear on other targets? Does that need to be captured and ignored? > > > > Thanks, David > > > > On Mon, Nov 16, 2020 at 11:46 AM Thomas Schwinge > > <thomas@codesourcery.com> wrote: > > > > > > Hi David! > > > > > > While you were writing your email, I've also been busy: > > > > > > On 2020-11-16T11:32:46-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > > > > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge <thomas@codesourcery.com> wrote: > > > >> On 2020-11-15T15:47:15-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > > > >> > I am seeing a number of new failures on AIX related to the OpenACC > > > >> > kernels patches. > > > >> > > > > >> > c-c++-common/goacc/kernels-decompose-1.c > > > >> > c-c++-common/goacc/kernels-decompose-2.c > > > >> > gfortran.dg/goacc/kernels-decompose-1.f95 > > > >> > gfortran.dg/goacc/kernels-decompose-2.f95 > > > >> > libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c > > > >> > libgomp.oacc-fortran/pr94358-1.f90 > > > >> > > > >> I suppose what you're asking about is what appears in > > > >> <gcc-testresults@gcc.gnu.org> reports as: > > > >> > > > >> ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " > > > >> UNRESOLVED: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " > > > >> > > > >> Etc. > > > > > > In the mean time, I did remember that weeks ago, I had noticed this > > > following "detail": on <https://www.tcl.tk/man/tcl8.5/TclCmd/incr.htm> we > > > read that "Starting with the Tcl 8.5 release, the variable 'varName' > > > passed to 'incr' may be unset, and in that case, it will be set to > > > [...]". Tcl 8.5 has been released in 2007. > > > > > > Per 'gcc/doc/install.texi' we require: > > > > > > @item DejaGnu 1.4.4 > > > @itemx Expect > > > @itemx Tcl > > > > > > Necessary to run the GCC testsuite; [...] > > > > > > DejaGnu has been released in 2004 (so cannot have required Tcl 8.5 > > > released in 2007). > > > > > > >> However, per the reports posted there, these really only (!) appear to > > > >> fail for your "Native configuration is powerpc-ibm-aix7.2.3.0" testing, > > > >> strange. Which versions of DejaGnu and Tcl are used? > > > > > > > > For my internal tester DejaGNU reports the following: > > > > > > > > Expect version is 5.42.1 > > > > Tcl version is 8.4 > > > > Framework version is 1.5.3 > > > > > > There we go: you're on Tcl 8.4. ;-D > > > > > > >> On <https://cfarm.tetaneutral.net/machines/list/> I see there are AIX > > > >> systems gcc111, gcc119 -- maybe I'll have luck reproducing the issue > > > >> there. > > > > > > On these, we've got: > > > > > > tschwinge@gcc111:[/home/tschwinge]/opt/freeware/bin/runtest --version > > > WARNING: Couldn't find the global config file. > > > Expect version is 5.45.4 > > > Tcl version is 8.6 > > > Framework version is 1.4.4 > > > > > > tschwinge@gcc119:[/home/tschwinge]/opt/freeware/bin/runtest --version > > > WARNING: Couldn't find the global config file. > > > Expect version is 5.44.1.15 > > > Tcl version is 8.5 > > > Framework version is 1.5.3 > > > > > > ..., so can't (easily) be used to reproduce the issue. (... but it > > > wouldn't be specific to AIX, anyway.) > > > > > > Before I spend time on building/verifying with Tcl 8.4: are you able to > > > give the attached patch "[testsuite] Avoid Tcl 8.5-specific behavior" a > > > try? > > > > > > > > > Grüße > > > Thomas > > > > > > > > > >> Admittedly, using Tcl code inside DejaGnu directives is not most common, > > > >> but it does make sense conceptually (at least to me), and reportedly does > > > >> work with a large number of DejaGnu/Tcl versions combinations. > > > >> > > > >> > Looking at the testsuite logs I see: > > > >> > > > > >> > fatal error: GCC is not configured to support amdgcn-amdhsa as offload target > > > >> > > > >> That one's not actually related to the new OpenACC 'kernels' testcases: > > > >> it's just the testsuite harness checking whether GCN offloading is > > > >> configured. (See <https://gcc.gnu.org/PR88920> "GCC is not configured to > > > >> support amdgcn-unknown-amdhsa as offload target"; this should one appear > > > >> once per testsuite.) > > > >> > > > >> > I don't know why this is different from the other OpenACC tests. > > > >> > > > >> It's not. At least not intentionally. > > > > > > > > I don't see any obvious difference in the style of the additional > > > > options for the kernels testcases versus others, although it > > > > specifically is using an option for that test. I only see the "GCC is > > > > not configured ... amdhsa" for those tests. > > > > > > > >> > > > >> > How > > > >> > should these tests be skipped or adjusted to not fail on other > > > >> > systems? > > > >> > > > >> They are expected to work fine on all systems; they're not specific to > > > >> actual code offloading. So if something FAILs, we shall resolve it. > > > > > > > > Thanks, David > > > > > > > > > ----------------- > > > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany > > > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-21 15:50 ` David Edelsohn @ 2020-11-24 10:19 ` Thomas Schwinge 2020-11-24 20:29 ` David Edelsohn 0 siblings, 1 reply; 12+ messages in thread From: Thomas Schwinge @ 2020-11-24 10:19 UTC (permalink / raw) To: David Edelsohn, gcc-patches [-- Attachment #1: Type: text/plain, Size: 8517 bytes --] Hi! On 2020-11-21T10:50:10-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > I see > > "during GIMPLE pass: omplower" > > message for kernels-decompose-ice-2.c. kernels-decompose-ice-1.c > explicitly prunes that output, but kernels-decompose-ice-2.c does not. > Is there a reason that the second testcase does not prune that output > or can we add it? So, the expectation (as verified by my x86_64-pc-linux-gnu and powerpc64le-unknown-linux-gnu testing) is that 'c-c++-common/goacc/kernels-decompose-ice-1.c' (currently) runs into an ICE "during GIMPLE pass: omplower", and 'c-c++-common/goacc/kernels-decompose-ice-2.c' (currently) runs into an ICE "during GIMPLE pass: omp_oacc_kernels_decompose". Now, you're reporting that for the latter testcase you're instead also seeing an ICE "during GIMPLE pass: omplower". Can you please show the full ICE report/backtrace, so that we verify that it's not yet another separate issue? Maybe the AIX system configuration (ABI?) mandates/causes some slight difference in how front ends set attributes such as 'TREE_ADDRESSABLE' on DECLs, which 'omp_oacc_kernels_decompose' (currently) is sensitive to (hence the ICEs). If you confirm that for 'c-c++-common/goacc/kernels-decompose-ice-2.c' you're seeing the same ICE "during GIMPLE pass: omplower" as seen for 'c-c++-common/goacc/kernels-decompose-ice-1.c', then it shall be fine to simply add 'dg-prune-output "during GIMPLE pass: omplower"' to 'c-c++-common/goacc/kernels-decompose-ice-2.c', too. (Please do it once you've verified/tested that, or I can do it later.) That said, I shall soon work on resolving these ICEs, so holding your breath until that happens would be another option. ;-) Then, for the Tcl issue: > On Tue, Nov 17, 2020 at 8:18 PM David Edelsohn <dje.gcc@gmail.com> wrote: >> The patch resolves the "no such variable" error message [...] >> >> I installed Tcl 8.6 with Expect 5.45. This removes the "no such >> variable" error messages for C and C++ test cases OK, thanks for confirming that. >> but they still >> occur for Fortran. (That's unexpected; it's the very same testsuite/Tcl constructs. Maybe just a manual testing glitch?) >> I guess that the patch is necessary because there seems to be >> something else still behaving differently on AIX. >> >> Any insights? >> On Tue, Nov 17, 2020 at 10:03 AM David Edelsohn <dje.gcc@gmail.com> wrote: >> > The standard version of Tcl installed on AIX currently is Tcl 8.4. Aha, thanks for confirming -- that indeed does explain the issue, good. >> > I'll see if I can have a newer version on the side. That's good for testing/confirming (as noted above), but I don't want to make Tcl 8.5+ a requirement just because of these testcases, so... >> > The patch resolves the "no such variable" error message. (Great! >> > Thanks!) ... I pushed "[testsuite] Avoid Tcl 8.5-specific behavior" to master branch in commit f72175357d04b0e71d2043be48551d7904a233b6, see attached. Grüße Thomas >> > On Mon, Nov 16, 2020 at 11:46 AM Thomas Schwinge >> > <thomas@codesourcery.com> wrote: >> > > >> > > Hi David! >> > > >> > > While you were writing your email, I've also been busy: >> > > >> > > On 2020-11-16T11:32:46-0500, David Edelsohn <dje.gcc@gmail.com> wrote: >> > > > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge <thomas@codesourcery.com> wrote: >> > > >> On 2020-11-15T15:47:15-0500, David Edelsohn <dje.gcc@gmail.com> wrote: >> > > >> > I am seeing a number of new failures on AIX related to the OpenACC >> > > >> > kernels patches. >> > > >> > >> > > >> > c-c++-common/goacc/kernels-decompose-1.c >> > > >> > c-c++-common/goacc/kernels-decompose-2.c >> > > >> > gfortran.dg/goacc/kernels-decompose-1.f95 >> > > >> > gfortran.dg/goacc/kernels-decompose-2.f95 >> > > >> > libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c >> > > >> > libgomp.oacc-fortran/pr94358-1.f90 >> > > >> >> > > >> I suppose what you're asking about is what appears in >> > > >> <gcc-testresults@gcc.gnu.org> reports as: >> > > >> >> > > >> ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " >> > > >> UNRESOLVED: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] " >> > > >> >> > > >> Etc. >> > > >> > > In the mean time, I did remember that weeks ago, I had noticed this >> > > following "detail": on <https://www.tcl.tk/man/tcl8.5/TclCmd/incr.htm> we >> > > read that "Starting with the Tcl 8.5 release, the variable 'varName' >> > > passed to 'incr' may be unset, and in that case, it will be set to >> > > [...]". Tcl 8.5 has been released in 2007. >> > > >> > > Per 'gcc/doc/install.texi' we require: >> > > >> > > @item DejaGnu 1.4.4 >> > > @itemx Expect >> > > @itemx Tcl >> > > >> > > Necessary to run the GCC testsuite; [...] >> > > >> > > DejaGnu has been released in 2004 (so cannot have required Tcl 8.5 >> > > released in 2007). >> > > >> > > >> However, per the reports posted there, these really only (!) appear to >> > > >> fail for your "Native configuration is powerpc-ibm-aix7.2.3.0" testing, >> > > >> strange. Which versions of DejaGnu and Tcl are used? >> > > > >> > > > For my internal tester DejaGNU reports the following: >> > > > >> > > > Expect version is 5.42.1 >> > > > Tcl version is 8.4 >> > > > Framework version is 1.5.3 >> > > >> > > There we go: you're on Tcl 8.4. ;-D >> > > >> > > >> On <https://cfarm.tetaneutral.net/machines/list/> I see there are AIX >> > > >> systems gcc111, gcc119 -- maybe I'll have luck reproducing the issue >> > > >> there. >> > > >> > > On these, we've got: >> > > >> > > tschwinge@gcc111:[/home/tschwinge]/opt/freeware/bin/runtest --version >> > > WARNING: Couldn't find the global config file. >> > > Expect version is 5.45.4 >> > > Tcl version is 8.6 >> > > Framework version is 1.4.4 >> > > >> > > tschwinge@gcc119:[/home/tschwinge]/opt/freeware/bin/runtest --version >> > > WARNING: Couldn't find the global config file. >> > > Expect version is 5.44.1.15 >> > > Tcl version is 8.5 >> > > Framework version is 1.5.3 >> > > >> > > ..., so can't (easily) be used to reproduce the issue. (... but it >> > > wouldn't be specific to AIX, anyway.) >> > > >> > > Before I spend time on building/verifying with Tcl 8.4: are you able to >> > > give the attached patch "[testsuite] Avoid Tcl 8.5-specific behavior" a >> > > try? >> > > >> > > >> > > Grüße >> > > Thomas >> > > >> > > >> > > >> Admittedly, using Tcl code inside DejaGnu directives is not most common, >> > > >> but it does make sense conceptually (at least to me), and reportedly does >> > > >> work with a large number of DejaGnu/Tcl versions combinations. >> > > >> >> > > >> > Looking at the testsuite logs I see: >> > > >> > >> > > >> > fatal error: GCC is not configured to support amdgcn-amdhsa as offload target >> > > >> >> > > >> That one's not actually related to the new OpenACC 'kernels' testcases: >> > > >> it's just the testsuite harness checking whether GCN offloading is >> > > >> configured. (See <https://gcc.gnu.org/PR88920> "GCC is not configured to >> > > >> support amdgcn-unknown-amdhsa as offload target"; this should one appear >> > > >> once per testsuite.) >> > > >> >> > > >> > I don't know why this is different from the other OpenACC tests. >> > > >> >> > > >> It's not. At least not intentionally. >> > > > >> > > > I don't see any obvious difference in the style of the additional >> > > > options for the kernels testcases versus others, although it >> > > > specifically is using an option for that test. I only see the "GCC is >> > > > not configured ... amdhsa" for those tests. >> > > > >> > > >> >> > > >> > How >> > > >> > should these tests be skipped or adjusted to not fail on other >> > > >> > systems? >> > > >> >> > > >> They are expected to work fine on all systems; they're not specific to >> > > >> actual code offloading. So if something FAILs, we shall resolve it. >> > > > >> > > > Thanks, David ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-testsuite-Avoid-Tcl-8.5-specific-behavior.patch --] [-- Type: text/x-diff, Size: 7138 bytes --] From f72175357d04b0e71d2043be48551d7904a233b6 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge <thomas@codesourcery.com> Date: Mon, 16 Nov 2020 17:37:06 +0100 Subject: [PATCH] [testsuite] Avoid Tcl 8.5-specific behavior gcc/ * doc/install.texi (Prerequisites) <Tcl>: Add comment. gcc/testsuite/ * c-c++-common/goacc/kernels-decompose-1.c: Avoid Tcl 8.5-specific behavior. * c-c++-common/goacc/kernels-decompose-2.c: Likewise. * gfortran.dg/goacc/kernels-decompose-1.f95: Likewise. * gfortran.dg/goacc/kernels-decompose-2.f95: Likewise. libgomp/ * testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c: Avoid Tcl 8.5-specific behavior. * testsuite/libgomp.oacc-fortran/pr94358-1.f90: Likewise. Reported-by: David Edelsohn <dje.gcc@gmail.com> --- gcc/doc/install.texi | 3 +++ gcc/testsuite/c-c++-common/goacc/kernels-decompose-1.c | 8 ++++++++ gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c | 8 ++++++++ gcc/testsuite/gfortran.dg/goacc/kernels-decompose-1.f95 | 8 ++++++++ gcc/testsuite/gfortran.dg/goacc/kernels-decompose-2.f95 | 8 ++++++++ .../libgomp.oacc-c-c++-common/kernels-decompose-1.c | 8 ++++++++ libgomp/testsuite/libgomp.oacc-fortran/pr94358-1.f90 | 8 ++++++++ 7 files changed, 51 insertions(+) diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi index cbfe859310a..8c55da373f8 100644 --- a/gcc/doc/install.texi +++ b/gcc/doc/install.texi @@ -464,6 +464,9 @@ Necessary when modifying @command{gperf} input files, e.g.@: @item DejaGnu 1.4.4 @itemx Expect @itemx Tcl +@c Once Tcl 8.5 or higher is required, remove any obsolete +@c compatibility workarounds: +@c git grep 'compatibility with earlier Tcl releases' Necessary to run the GCC testsuite; see the section on testing for details. diff --git a/gcc/testsuite/c-c++-common/goacc/kernels-decompose-1.c b/gcc/testsuite/c-c++-common/goacc/kernels-decompose-1.c index 92db33273eb..e906443cceb 100644 --- a/gcc/testsuite/c-c++-common/goacc/kernels-decompose-1.c +++ b/gcc/testsuite/c-c++-common/goacc/kernels-decompose-1.c @@ -7,6 +7,14 @@ /* See also '../../gfortran.dg/goacc/kernels-decompose-1.f95'. */ +/* It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' + passed to 'incr' may be unset, and in that case, it will be set to [...]", + so to maintain compatibility with earlier Tcl releases, we manually + initialize counter variables: + { dg-line l_dummy[variable c_loop_i 0] } + { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid + "WARNING: dg-line var l_dummy defined, but not used". */ + #define N 1024 unsigned int a[N]; diff --git a/gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c b/gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c index ec6c4af92aa..ec0f75c4a61 100644 --- a/gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c +++ b/gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c @@ -6,6 +6,14 @@ /* See also '../../gfortran.dg/goacc/kernels-decompose-2.f95'. */ +/* It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' + passed to 'incr' may be unset, and in that case, it will be set to [...]", + so to maintain compatibility with earlier Tcl releases, we manually + initialize counter variables: + { dg-line l_dummy[variable c_loop_i 0 c_loop_j 0 c_loop_k 0 c_part 0] } + { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid + "WARNING: dg-line var l_dummy defined, but not used". */ + #pragma acc routine gang extern int f_g (int); diff --git a/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-1.f95 b/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-1.f95 index 95a78623ebf..7e513f84083 100644 --- a/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-1.f95 +++ b/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-1.f95 @@ -7,6 +7,14 @@ ! See also '../../c-c++-common/goacc/kernels-decompose-1.c'. +! It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' +! passed to 'incr' may be unset, and in that case, it will be set to [...]", +! so to maintain compatibility with earlier Tcl releases, we manually +! initialize counter variables: +! { dg-line l_dummy[variable c_loop_i 0] } +! { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid +! "WARNING: dg-line var l_dummy defined, but not used". + program main implicit none integer, parameter :: N = 1024 diff --git a/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-2.f95 b/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-2.f95 index 58d687d4a0c..22f65e5c694 100644 --- a/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-2.f95 +++ b/gcc/testsuite/gfortran.dg/goacc/kernels-decompose-2.f95 @@ -6,6 +6,14 @@ ! See also '../../c-c++-common/goacc/kernels-decompose-2.c'. +! It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' +! passed to 'incr' may be unset, and in that case, it will be set to [...]", +! so to maintain compatibility with earlier Tcl releases, we manually +! initialize counter variables: +! { dg-line l_dummy[variable c_loop_i 0 c_loop_j 0 c_loop_k 0 c_part 0] } +! { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid +! "WARNING: dg-line var l_dummy defined, but not used". + program main implicit none diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c index fa8ae6c79cd..e76e4099f3a 100644 --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c @@ -3,6 +3,14 @@ /* { dg-additional-options "-fopt-info-omp-all" } */ /* { dg-additional-options "-fopenacc-kernels=decompose" } */ +/* It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' + passed to 'incr' may be unset, and in that case, it will be set to [...]", + so to maintain compatibility with earlier Tcl releases, we manually + initialize counter variables: + { dg-line l_dummy[variable c_loop_i 0] } + { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid + "WARNING: dg-line var l_dummy defined, but not used". */ + #undef NDEBUG #include <assert.h> diff --git a/libgomp/testsuite/libgomp.oacc-fortran/pr94358-1.f90 b/libgomp/testsuite/libgomp.oacc-fortran/pr94358-1.f90 index 82d8351f0e3..99a70418a4d 100644 --- a/libgomp/testsuite/libgomp.oacc-fortran/pr94358-1.f90 +++ b/libgomp/testsuite/libgomp.oacc-fortran/pr94358-1.f90 @@ -2,6 +2,14 @@ ! { dg-additional-options "-fopt-info-omp-all" } ! { dg-additional-options "-fopenacc-kernels=decompose" } +! It's only with Tcl 8.5 (released in 2007) that "the variable 'varName' +! passed to 'incr' may be unset, and in that case, it will be set to [...]", +! so to maintain compatibility with earlier Tcl releases, we manually +! initialize counter variables: +! { dg-line l_dummy[variable c_loop_i 0] } +! { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid +! "WARNING: dg-line var l_dummy defined, but not used". + subroutine kernel(lo, hi, a, b, c) implicit none integer :: lo, hi, i -- 2.17.1 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-24 10:19 ` Thomas Schwinge @ 2020-11-24 20:29 ` David Edelsohn 2020-11-27 14:15 ` Thomas Schwinge 0 siblings, 1 reply; 12+ messages in thread From: David Edelsohn @ 2020-11-24 20:29 UTC (permalink / raw) To: Thomas Schwinge; +Cc: GCC Patches On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge <thomas@codesourcery.com> wrote: > > Hi! > > On 2020-11-21T10:50:10-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > > I see > > > > "during GIMPLE pass: omplower" > > > > message for kernels-decompose-ice-2.c. kernels-decompose-ice-1.c > > explicitly prunes that output, but kernels-decompose-ice-2.c does not. > > Is there a reason that the second testcase does not prune that output > > or can we add it? > > So, the expectation (as verified by my x86_64-pc-linux-gnu and > powerpc64le-unknown-linux-gnu testing) is that > 'c-c++-common/goacc/kernels-decompose-ice-1.c' (currently) runs into an > ICE "during GIMPLE pass: omplower", and > 'c-c++-common/goacc/kernels-decompose-ice-2.c' (currently) runs into an > ICE "during GIMPLE pass: omp_oacc_kernels_decompose". > > Now, you're reporting that for the latter testcase you're instead also > seeing an ICE "during GIMPLE pass: omplower". Can you please show the > full ICE report/backtrace, so that we verify that it's not yet another > separate issue? Maybe the AIX system configuration (ABI?) > mandates/causes some slight difference in how front ends set attributes > such as 'TREE_ADDRESSABLE' on DECLs, which 'omp_oacc_kernels_decompose' > (currently) is sensitive to (hence the ICEs). If you confirm that for > 'c-c++-common/goacc/kernels-decompose-ice-2.c' you're seeing the same > ICE "during GIMPLE pass: omplower" as seen for > 'c-c++-common/goacc/kernels-decompose-ice-1.c', then it shall be fine to > simply add 'dg-prune-output "during GIMPLE pass: omplower"' to > 'c-c++-common/goacc/kernels-decompose-ice-2.c', too. (Please do it once > you've verified/tested that, or I can do it later.) The error messages reported on AIX are: Executing on host: /tmp/GCC/gcc/xgcc -B/tmp/GCC/gcc/ /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c -fdiagnostics-plain-output -fopenacc -fopenacc-kernels=decompose -S -o kernels-decompose-ice-2.s (timeout = 300) spawn -ignore SIGHUP /tmp/GCC/gcc/xgcc -B/tmp/GCC/gcc/ /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c -fdiagnostics-plain-output -fopenacc -fopenacc-kernels=decompose -S -o kernels-decompose-ice-2.s during GIMPLE pass: omplower /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c: In function 'main': /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c:13:9: internal compiler error: in lower_omp_target, at omp-low.c:12216 ranges offset out of range Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. compiler exited with status 1 Thanks, David ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-24 20:29 ` David Edelsohn @ 2020-11-27 14:15 ` Thomas Schwinge 2020-11-27 15:47 ` David Edelsohn 0 siblings, 1 reply; 12+ messages in thread From: Thomas Schwinge @ 2020-11-27 14:15 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc-patches Hi David! On 2020-11-24T15:29:17-0500, David Edelsohn via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge <thomas@codesourcery.com> wrote: >> On 2020-11-21T10:50:10-0500, David Edelsohn <dje.gcc@gmail.com> wrote: >> > I see >> > >> > "during GIMPLE pass: omplower" >> > >> > message for kernels-decompose-ice-2.c. kernels-decompose-ice-1.c >> > explicitly prunes that output, but kernels-decompose-ice-2.c does not. >> > Is there a reason that the second testcase does not prune that output >> > or can we add it? >> >> So, the expectation (as verified by my x86_64-pc-linux-gnu and >> powerpc64le-unknown-linux-gnu testing) is that >> 'c-c++-common/goacc/kernels-decompose-ice-1.c' (currently) runs into an >> ICE "during GIMPLE pass: omplower", and >> 'c-c++-common/goacc/kernels-decompose-ice-2.c' (currently) runs into an >> ICE "during GIMPLE pass: omp_oacc_kernels_decompose". >> >> Now, you're reporting that for the latter testcase you're instead also >> seeing an ICE "during GIMPLE pass: omplower". Can you please show the >> full ICE report/backtrace, so that we verify that it's not yet another >> separate issue? On gcc119 ('uname -a': "AIX power8-aix 2 7 00F9C1964C00"), I've now also reproduced the issue. >> Maybe the AIX system configuration (ABI?) >> mandates/causes some slight difference in how front ends set attributes >> such as 'TREE_ADDRESSABLE' on DECLs, which 'omp_oacc_kernels_decompose' >> (currently) is sensitive to (hence the ICEs). That's not the case; the input into 'omp_oacc_kernels_decompose' seems to be exactly the same as on other systems. > The error messages reported on AIX are: > > Executing on host: /tmp/GCC/gcc/xgcc -B/tmp/GCC/gcc/ /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c -fdiagnostics-plain-output -fopenacc -fopenacc-kernels=decompose -S -o kernels-decompose-ice-2.s (timeout = 300) > spawn -ignore SIGHUP /tmp/GCC/gcc/xgcc -B/tmp/GCC/gcc/ /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c -fdiagnostics-plain-output -fopenacc -fopenacc-kernels=decompose -S -o kernels-decompose-ice-2.s > during GIMPLE pass: omplower > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c: In function 'main': > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c:13:9: > internal compiler error: in lower_omp_target, at omp-low.c:12216 That's indeed the location of the 'gcc_assert' responsible for the 'omplower' ICE, which currently is expected, if we don't run into the 'omp_oacc_kernels_decompose' ICE first. It's still strange however, why we're seeing this "for AIX" (not better classified) only: I suppose it isn't a feature "of AIX" that it can dereference a 'NULL' pointer ;-) -- which is what seems to be happening here: 742 gimple_seq inner_sequence = gimple_bind_body (inner_bind); (gdb) next 743 gcc_assert (gimple_code (inner_sequence) != GIMPLE_BIND (gdb) print inner_sequence $1 = (gimple_seq) 0x0 (gdb) next 745 gimple_seq_add_seq (&new_body, inner_sequence); So we have 'inner_sequence == NULL', and yet the 'next' didn't trigger a SIGSEGV in: static inline enum gimple_code gimple_code (const gimple *g) { return g->code; } Strange, isn't it? However: this issue should now (indirectly) be fixed via "In 'gcc/omp-oacc-kernels-decompose.cc:flatten_binds', don't choke on empty GIMPLE sequence" that I've just pushed to master branch in commit 4b5726fda653d11f882fb9a112e4cffa12f7ed61. > during GIMPLE pass: omplower > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c: In function 'main': > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c:13:9: > internal compiler error: in lower_omp_target, at omp-low.c:12216 > ranges offset out of range That last line actually comes from here: libbacktrace/dwarf.c: error_callback (data, "ranges offset out of range", 0); Grüße Thomas ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-27 14:15 ` Thomas Schwinge @ 2020-11-27 15:47 ` David Edelsohn 2020-11-27 16:01 ` Thomas Schwinge 0 siblings, 1 reply; 12+ messages in thread From: David Edelsohn @ 2020-11-27 15:47 UTC (permalink / raw) To: Thomas Schwinge; +Cc: GCC Patches Hi, Thomas Actually, yes, AIX does allow dereference of a NULL pointer. Thanks, David On Fri, Nov 27, 2020 at 9:15 AM Thomas Schwinge <thomas@codesourcery.com> wrote: > > Hi David! > > On 2020-11-24T15:29:17-0500, David Edelsohn via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge <thomas@codesourcery.com> wrote: > >> On 2020-11-21T10:50:10-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > >> > I see > >> > > >> > "during GIMPLE pass: omplower" > >> > > >> > message for kernels-decompose-ice-2.c. kernels-decompose-ice-1.c > >> > explicitly prunes that output, but kernels-decompose-ice-2.c does not. > >> > Is there a reason that the second testcase does not prune that output > >> > or can we add it? > >> > >> So, the expectation (as verified by my x86_64-pc-linux-gnu and > >> powerpc64le-unknown-linux-gnu testing) is that > >> 'c-c++-common/goacc/kernels-decompose-ice-1.c' (currently) runs into an > >> ICE "during GIMPLE pass: omplower", and > >> 'c-c++-common/goacc/kernels-decompose-ice-2.c' (currently) runs into an > >> ICE "during GIMPLE pass: omp_oacc_kernels_decompose". > >> > >> Now, you're reporting that for the latter testcase you're instead also > >> seeing an ICE "during GIMPLE pass: omplower". Can you please show the > >> full ICE report/backtrace, so that we verify that it's not yet another > >> separate issue? > > On gcc119 ('uname -a': "AIX power8-aix 2 7 00F9C1964C00"), I've now also > reproduced the issue. > > >> Maybe the AIX system configuration (ABI?) > >> mandates/causes some slight difference in how front ends set attributes > >> such as 'TREE_ADDRESSABLE' on DECLs, which 'omp_oacc_kernels_decompose' > >> (currently) is sensitive to (hence the ICEs). > > That's not the case; the input into 'omp_oacc_kernels_decompose' seems to > be exactly the same as on other systems. > > > The error messages reported on AIX are: > > > > Executing on host: /tmp/GCC/gcc/xgcc -B/tmp/GCC/gcc/ /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c -fdiagnostics-plain-output -fopenacc -fopenacc-kernels=decompose -S -o kernels-decompose-ice-2.s (timeout = 300) > > spawn -ignore SIGHUP /tmp/GCC/gcc/xgcc -B/tmp/GCC/gcc/ /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c -fdiagnostics-plain-output -fopenacc -fopenacc-kernels=decompose -S -o kernels-decompose-ice-2.s > > during GIMPLE pass: omplower > > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c: In function 'main': > > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c:13:9: > > internal compiler error: in lower_omp_target, at omp-low.c:12216 > > That's indeed the location of the 'gcc_assert' responsible for the > 'omplower' ICE, which currently is expected, if we don't run into the > 'omp_oacc_kernels_decompose' ICE first. It's still strange however, why > we're seeing this "for AIX" (not better classified) only: I suppose it > isn't a feature "of AIX" that it can dereference a 'NULL' pointer ;-) -- > which is what seems to be happening here: > > 742 gimple_seq inner_sequence = gimple_bind_body (inner_bind); > (gdb) next > 743 gcc_assert (gimple_code (inner_sequence) != GIMPLE_BIND > (gdb) print inner_sequence > $1 = (gimple_seq) 0x0 > (gdb) next > 745 gimple_seq_add_seq (&new_body, inner_sequence); > > So we have 'inner_sequence == NULL', and yet the 'next' didn't trigger a > SIGSEGV in: > > static inline enum gimple_code > gimple_code (const gimple *g) > { > return g->code; > } > > Strange, isn't it? > > > However: this issue should now (indirectly) be fixed via "In > 'gcc/omp-oacc-kernels-decompose.cc:flatten_binds', don't choke on empty > GIMPLE sequence" that I've just pushed to master branch in commit > 4b5726fda653d11f882fb9a112e4cffa12f7ed61. > > > > during GIMPLE pass: omplower > > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c: In function 'main': > > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c:13:9: > > internal compiler error: in lower_omp_target, at omp-low.c:12216 > > ranges offset out of range > > That last line actually comes from here: > > libbacktrace/dwarf.c: error_callback (data, "ranges offset out of range", 0); > > > Grüße > Thomas > ----------------- > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenACC 'kernels' testsuite failures 2020-11-27 15:47 ` David Edelsohn @ 2020-11-27 16:01 ` Thomas Schwinge 0 siblings, 0 replies; 12+ messages in thread From: Thomas Schwinge @ 2020-11-27 16:01 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc-patches Hi David! On 2020-11-27T10:47:17-0500, David Edelsohn <dje.gcc@gmail.com> wrote: > Actually, yes, AIX does allow dereference of a NULL pointer. Oh. That's not what I expected! Heh. Anyway, that then indeed completely explains what was going on here -- which is good. :-) Grüße Thomas > On Fri, Nov 27, 2020 at 9:15 AM Thomas Schwinge <thomas@codesourcery.com> wrote: >> >> Hi David! >> >> On 2020-11-24T15:29:17-0500, David Edelsohn via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: >> > On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge <thomas@codesourcery.com> wrote: >> >> On 2020-11-21T10:50:10-0500, David Edelsohn <dje.gcc@gmail.com> wrote: >> >> > I see >> >> > >> >> > "during GIMPLE pass: omplower" >> >> > >> >> > message for kernels-decompose-ice-2.c. kernels-decompose-ice-1.c >> >> > explicitly prunes that output, but kernels-decompose-ice-2.c does not. >> >> > Is there a reason that the second testcase does not prune that output >> >> > or can we add it? >> >> >> >> So, the expectation (as verified by my x86_64-pc-linux-gnu and >> >> powerpc64le-unknown-linux-gnu testing) is that >> >> 'c-c++-common/goacc/kernels-decompose-ice-1.c' (currently) runs into an >> >> ICE "during GIMPLE pass: omplower", and >> >> 'c-c++-common/goacc/kernels-decompose-ice-2.c' (currently) runs into an >> >> ICE "during GIMPLE pass: omp_oacc_kernels_decompose". >> >> >> >> Now, you're reporting that for the latter testcase you're instead also >> >> seeing an ICE "during GIMPLE pass: omplower". Can you please show the >> >> full ICE report/backtrace, so that we verify that it's not yet another >> >> separate issue? >> >> On gcc119 ('uname -a': "AIX power8-aix 2 7 00F9C1964C00"), I've now also >> reproduced the issue. >> >> >> Maybe the AIX system configuration (ABI?) >> >> mandates/causes some slight difference in how front ends set attributes >> >> such as 'TREE_ADDRESSABLE' on DECLs, which 'omp_oacc_kernels_decompose' >> >> (currently) is sensitive to (hence the ICEs). >> >> That's not the case; the input into 'omp_oacc_kernels_decompose' seems to >> be exactly the same as on other systems. >> >> > The error messages reported on AIX are: >> > >> > Executing on host: /tmp/GCC/gcc/xgcc -B/tmp/GCC/gcc/ /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c -fdiagnostics-plain-output -fopenacc -fopenacc-kernels=decompose -S -o kernels-decompose-ice-2.s (timeout = 300) >> > spawn -ignore SIGHUP /tmp/GCC/gcc/xgcc -B/tmp/GCC/gcc/ /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c -fdiagnostics-plain-output -fopenacc -fopenacc-kernels=decompose -S -o kernels-decompose-ice-2.s >> > during GIMPLE pass: omplower >> > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c: In function 'main': >> > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c:13:9: >> > internal compiler error: in lower_omp_target, at omp-low.c:12216 >> >> That's indeed the location of the 'gcc_assert' responsible for the >> 'omplower' ICE, which currently is expected, if we don't run into the >> 'omp_oacc_kernels_decompose' ICE first. It's still strange however, why >> we're seeing this "for AIX" (not better classified) only: I suppose it >> isn't a feature "of AIX" that it can dereference a 'NULL' pointer ;-) -- >> which is what seems to be happening here: >> >> 742 gimple_seq inner_sequence = gimple_bind_body (inner_bind); >> (gdb) next >> 743 gcc_assert (gimple_code (inner_sequence) != GIMPLE_BIND >> (gdb) print inner_sequence >> $1 = (gimple_seq) 0x0 >> (gdb) next >> 745 gimple_seq_add_seq (&new_body, inner_sequence); >> >> So we have 'inner_sequence == NULL', and yet the 'next' didn't trigger a >> SIGSEGV in: >> >> static inline enum gimple_code >> gimple_code (const gimple *g) >> { >> return g->code; >> } >> >> Strange, isn't it? >> >> >> However: this issue should now (indirectly) be fixed via "In >> 'gcc/omp-oacc-kernels-decompose.cc:flatten_binds', don't choke on empty >> GIMPLE sequence" that I've just pushed to master branch in commit >> 4b5726fda653d11f882fb9a112e4cffa12f7ed61. >> >> >> > during GIMPLE pass: omplower >> > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c: In function 'main': >> > /nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c:13:9: >> > internal compiler error: in lower_omp_target, at omp-low.c:12216 >> > ranges offset out of range >> >> That last line actually comes from here: >> >> libbacktrace/dwarf.c: error_callback (data, "ranges offset out of range", 0); >> >> >> Grüße >> Thomas >> ----------------- >> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany >> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-11-27 16:01 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-15 20:47 OpenACC 'kernels' testsuite failures David Edelsohn 2020-11-16 14:16 ` Thomas Schwinge 2020-11-16 16:32 ` David Edelsohn 2020-11-16 16:46 ` Thomas Schwinge 2020-11-17 15:03 ` David Edelsohn 2020-11-18 1:18 ` David Edelsohn 2020-11-21 15:50 ` David Edelsohn 2020-11-24 10:19 ` Thomas Schwinge 2020-11-24 20:29 ` David Edelsohn 2020-11-27 14:15 ` Thomas Schwinge 2020-11-27 15:47 ` David Edelsohn 2020-11-27 16:01 ` Thomas Schwinge
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).