Re: OpenACC 'kernels' testsuite failures

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn]

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

Re: OpenACC 'kernels' testsuite failures

[Thomas Schwinge]

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

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn]

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

Re: OpenACC 'kernels' testsuite failures

[Thomas Schwinge]

[-- 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

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn]

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

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn]

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

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn]

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

Re: OpenACC 'kernels' testsuite failures

[Thomas Schwinge]

[-- 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

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn]

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

Re: OpenACC 'kernels' testsuite failures

[Thomas Schwinge]

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

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn]

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

Re: OpenACC 'kernels' testsuite failures

[Thomas Schwinge]

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