On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge <tho...@codesourcery.com> wrote:
>
> Hi Richard!
>
> On 2022-05-03T09:17:52+0200, Richard Biener <richard.guent...@gmail.com>
> wrote:
> > On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge <tho...@codesourcery.com>
> > wrote:
> >> On 2022-05-01T11:02:29+0100, Iain Sandoe via Gcc <g...@gcc.gnu.org> wrote:
> >> >> On 29 Apr 2022, at 15:34, Jakub Jelinek via Gcc <g...@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".
I think that is misguided.
> 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.
So maybe do
internal_error ("PRnnnn");
then?
>
> 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
