Hi David!

On 2020-11-27T10:47:17-0500, David Edelsohn <dje....@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 <tho...@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 <tho...@codesourcery.com> 
>> > wrote:
>> >> On 2020-11-21T10:50:10-0500, David Edelsohn <dje....@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

Reply via email to