Re: OpenACC 'kernels' testsuite failures

[Thomas Schwinge]

Hi David!

On 2020-11-27T10:47:17-0500, David Edelsohn  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  
> wrote:
>>
>> Hi David!
>>
>> On 2020-11-24T15:29:17-0500, David Edelsohn via Gcc-patches 
>>  wrote:
>> > On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge  
>> > wrote:
>> >> On 2020-11-21T10:50:10-0500, David Edelsohn  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 / G

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn via 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  wrote:
>
> Hi David!
>
> On 2020-11-24T15:29:17-0500, David Edelsohn via Gcc-patches 
>  wrote:
> > On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge  
> > wrote:
> >> On 2020-11-21T10:50:10-0500, David Edelsohn  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-24T15:29:17-0500, David Edelsohn via Gcc-patches 
 wrote:
> On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge  
> wrote:
>> On 2020-11-21T10:50:10-0500, David Edelsohn  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 via Gcc-patches]

On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge  wrote:
>
> Hi!
>
> On 2020-11-21T10:50:10-0500, David Edelsohn  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  for instructions.
compiler exited with status 1

Thanks, David

Re: OpenACC 'kernels' testsuite failures

[Thomas Schwinge]

Hi!

On 2020-11-21T10:50:10-0500, David Edelsohn  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  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  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
>> >  wrote:
>> > >
>> > > Hi David!
>> > >
>> > > While you were writing your email, I've also been busy:
>> > >
>> > > On 2020-11-16T11:32:46-0500, David Edelsohn  wrote:
>> > > > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge 
>> > > >  wrote:
>> > > >> On 2020-11-15T15:47:15-0500, David Edelsohn  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
>> > > >>  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  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 "

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn via 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  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  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
> >  wrote:
> > >
> > > Hi David!
> > >
> > > While you were writing your email, I've also been busy:
> > >
> > > On 2020-11-16T11:32:46-0500, David Edelsohn  wrote:
> > > > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge 
> > > >  wrote:
> > > >> On 2020-11-15T15:47:15-0500, David Edelsohn  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
> > > >>  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  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  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 is1.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 is1.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

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn via 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  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
>  wrote:
> >
> > Hi David!
> >
> > While you were writing your email, I've also been busy:
> >
> > On 2020-11-16T11:32:46-0500, David Edelsohn  wrote:
> > > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge  
> > > wrote:
> > >> On 2020-11-15T15:47:15-0500, David Edelsohn  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
> > >>  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  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  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 is1.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 is1.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  "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.
> > >>

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn via 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
 wrote:
>
> Hi David!
>
> While you were writing your email, I've also been busy:
>
> On 2020-11-16T11:32:46-0500, David Edelsohn  wrote:
> > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge  
> > wrote:
> >> On 2020-11-15T15:47:15-0500, David Edelsohn  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
> >>  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  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  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 is1.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 is1.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  "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 1

Re: OpenACC 'kernels' testsuite failures

[Thomas Schwinge]

Hi David!

While you were writing your email, I've also been busy:

On 2020-11-16T11:32:46-0500, David Edelsohn  wrote:
> On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge  
> wrote:
>> On 2020-11-15T15:47:15-0500, David Edelsohn  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
>>  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  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  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 is1.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 is1.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  "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
>From cde6156007fbf6376851d2343d8870a98998773d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
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 fi

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn via Gcc-patches]

On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge  wrote:
>
> Hi David!
>
> Thanks for reporting.
>
> On 2020-11-15T15:47:15-0500, David Edelsohn  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
>  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  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  "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]

Hi David!

Thanks for reporting.

On 2020-11-15T15:47:15-0500, David Edelsohn  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
 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  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  "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 via 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