Re: OpenACC 'kernels' testsuite failures

[Thomas Schwinge <thomas@codesourcery.com>]

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