Re: Make 'c-c++-common/goacc/kernels-decompose-pr100400-1-*.c' behave consistently, regardless of checking level

[Thomas Schwinge <thomas@codesourcery.com>]

Hi Richard!

On 2022-05-03T09:17:52+0200, Richard Biener <richard.guenther@gmail.com> wrote:
> On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge <thomas@codesourcery.com> wrote:
>> On 2022-05-01T11:02:29+0100, Iain Sandoe via Gcc <gcc@gcc.gnu.org> wrote:
>> >> On 29 Apr 2022, at 15:34, Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
>> >>
>> >> The first release candidate for GCC 12.1 is available from
>> >>
>> >> https://gcc.gnu.org/pub/gcc/snapshots/12.1.0-RC-20220429/
>> >> ftp://gcc.gnu.org/pub/gcc/snapshots/12.1.0-RC-20220429/
>> >>
>> >> and shortly its mirrors.  It has been generated from git commit
>> >> r12-8321-g621650f64fb667.
>>
>> > [...] new fails (presumably because checking is off):
>>
>> > XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c  -std=c++98 (internal compiler error)
>> > FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c  -std=c++98 (test for excess errors)
>> > XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c  -std=c++14 (internal compiler error)
>> > FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c  -std=c++14 (test for excess errors)
>> > XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c  -std=c++17 (internal compiler error)
>> > FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c  -std=c++17 (test for excess errors)
>> > XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c  -std=c++20 (internal compiler error)
>> > FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c  -std=c++20 (test for excess errors)
>>
>> Confirmed, and sorry.  I had taken care to add explicit '-fchecking'
>> next to 'dg-ice', but that's in fact not the problem/cure here.
>> OK to push to the relevant branches the attached
>> "Make 'c-c++-common/goacc/kernels-decompose-pr100400-1-*.c' behave
>> consistently, regardless of checking level"?
>
> No,
>
> +++ b/gcc/omp-oacc-kernels-decompose.cc
> @@ -239,7 +239,13 @@ visit_loops_in_gang_single_region
> (gimple_stmt_iterator *gsi_p,
>      case GIMPLE_OMP_FOR:
>        /*TODO Given the current 'adjust_region_code' algorithm, this is
>         actually...  */
> +#if 0
>        gcc_unreachable ();
> +#else
> +      /* ..., but due to bugs (PR100400), we may actually come here.
> +        Reliably catch this, regardless of checking level.  */
> +      abort ();
> +#endif
>
> this doesn't look correct.  If you want a reliable diagnostic here please use
> sorry ("...") or call internal_error () manually (the IL verifiers do this).

Hmm, I feel I'm going in circles...  ;-)

Here, 'sorry' isn't appropriate, because this is a plain bug, and not
"a language feature which is required by the relevant specification but
not implemented by GCC" ('gcc/diagnostic.cc').

I first had this as 'internal_error', but then saw the following source
code comment, 'gcc/diagnostic.cc':

    /* An internal consistency check has failed.  We make no attempt to
       continue.  Note that unless there is debugging value to be had from
       a more specific message, or some other good reason, you should use
       abort () instead of calling this function directly.  */
    void
    internal_error (const char *gmsgid, ...)
    {

Here, there's no "debugging value to be had from a more specific
message", and I couldn't think of "some other good reason", so decided to
"use abort () instead of calling this function directly".

But, if that's what we want, I'm happy to again switch to
'internal_error', and then we should update this source code comment,
too?


> That said, having a testcase that checks for an ICE as a TODO is maybe not
> the very best thing to have.  We have bugzilla for unfixed bugs.

As per the past 'dg-ice' discussions, there's certainly value seen for
having such test cases (and it already did help me during development,
elsewhere).

I do agree/acknowledge that it's a bit more difficult to make those
behave consistently across GCC configurations.


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955