This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gomp4, nvptx, committed] Fix assert in nvptx_propagate_unified


Hi Tom!

On Fri, 30 Jun 2017 17:15:24 +0200, Tom de Vries <Tom_deVries@mentor.com> wrote:
> with the openacc test-case in attached patch, I ran into an assert here:

Using your test case, in my build with
"--enable-checking=yes,df,fold,rtl", I already earlier run into an ICE...

> static void
> nvptx_propagate_unified (rtx_insn *unified)
> {
>     rtx_insn *probe = unified;
>     rtx cond_reg = SET_DEST (PATTERN (unified));
>     rtx pat;
> 
>     /* Find the comparison.  (We could skip this and simply scan to he
>        blocks' terminating branch, if we didn't care for self
>        checking.)  */
>     for (;;)
>       {
>         probe = NEXT_INSN (probe);
>         pat = PATTERN (probe);

... here:

    [...]/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-cplx-flt-2.c:19:9: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx note) in PATTERN, at rtl.h:1440

    Breakpoint 2, internal_error (gmsgid=0x10cc840 "RTL check: expected elt %d type '%c' or '%c', have '%c' (rtx %s) in %s, at %s:%d") at [...]/gcc/diagnostic.c:1251
    1251    {
    (gdb) bt
    #0  internal_error (gmsgid=0x10cc840 "RTL check: expected elt %d type '%c' or '%c', have '%c' (rtx %s) in %s, at %s:%d") at [...]/gcc/diagnostic.c:1251
    #1  0x00000000009bd2c7 in rtl_check_failed_type2 (r=0x7ffff688cd40, n=<optimized out>, c1=<optimized out>, c2=<optimized out>, file=<optimized out>, line=<optimized out>, func=0x106ac48 <_ZZ7PATTERNP7rtx_defE12__FUNCTION__> "PATTERN") at [...]/gcc/rtl.c:802
    #2  0x0000000000529ef3 in PATTERN (insn=<optimized out>) at [...]/gcc/rtl.h:1440
    #3  0x00000000005e5a2b in PATTERN (insn=<optimized out>) at [...]/gcc/rtl.h:1440
    #4  0x0000000000d08b96 in nvptx_propagate_unified (unified=0x7ffff688ccc0) at [...]/gcc/config/nvptx/nvptx.c:2299
    #5  0x0000000000d093e7 in nvptx_split_blocks (map=map@entry=0x7fffffffcc40) at [...]/gcc/config/nvptx/nvptx.c:2428
    #6  0x0000000000d0d08b in nvptx_reorg () at [...]/gcc/config/nvptx/nvptx.c:3840
    #7  0x00000000009bb0ea in (anonymous namespace)::pass_machine_reorg::execute (this=<optimized out>) at [...]/gcc/reorg.c:3952
    [...]
    (gdb) frame 4
    #4  0x0000000000d08b96 in nvptx_propagate_unified (unified=0x7ffff688ccc0) at [...]/gcc/config/nvptx/nvptx.c:2299
    2299          pat = PATTERN (probe);
    (gdb) print probe
    $1 = (rtx_insn *) 0x7ffff688cd40
    (gdb) call debug_rtx(probe)
    (note 56 54 57 3 NOTE_INSN_DELETED)

> 
>         if (GET_CODE (pat) == SET
>             && GET_RTX_CLASS (GET_CODE (SET_SRC (pat))) == RTX_COMPARE
>             && XEXP (SET_SRC (pat), 0) == cond_reg)
>       break;
>         gcc_assert (NONJUMP_INSN_P (probe));
>       }
> ...
> 
> The assert happens when processing insn 56:
> ...
> (insn 54 53 56 3 (set (reg:SI 47 [ _71 ])
>            (unspec:SI [
>                    (reg:SI 36 [ _58 ])
>                ] UNSPEC_BR_UNIFIED)) 108 {cond_uni}
>         (nil))
> (note 56 54 57 3 NOTE_INSN_DELETED)
> (insn 57 56 58 3 (set (reg:BI 68)
>            (gt:BI (reg:SI 47 [ _71 ])
>                (const_int 1 [0x1]))) 99 {*cmpsi}
>         (expr_list:REG_DEAD (reg:SI 47 [ _71 ])
>            (nil)))
> ...
> The insn 56 was originally a '(set (reg x) (const_int 1))', but that one 
> has been combined into insn 57 and replaced with a 'NOTE_INSN_DELETED'. 
> So it seems reasonable for the loop to skip over this note.
> 
> Fixed by making the assert condition less strict.
> 
> Build on x86_64 with nvptx accelerator.
> 
> Tested test-case included in the patch.
> 
> Committed as trivial.

> --- a/gcc/config/nvptx/nvptx.c
> +++ b/gcc/config/nvptx/nvptx.c
> @@ -2300,7 +2300,7 @@ nvptx_propagate_unified (rtx_insn *unified)
>  	  && GET_RTX_CLASS (GET_CODE (SET_SRC (pat))) == RTX_COMPARE
>  	  && XEXP (SET_SRC (pat), 0) == cond_reg)
>  	break;
> -      gcc_assert (NONJUMP_INSN_P (probe));
> +      gcc_assert (NONJUMP_INSN_P (probe) || !INSN_P (probe));
>      }
>    rtx pred_reg = SET_DEST (pat);

These problems (both yours and mine) do not reproduce on trunk, right?
But I suppose these are still a latent, just waiting for a different test
case?  Maybe this is a case to write an RTL-level test case?  (Unless the
fix is deemed trivial enough to warrent spending time on this.)

Anyway, I don't know a lot about RTL, but the following patch does cure
this test case (now running other testing).  Would you please check that,
and also whether nvptx_propagate_unified then still works as expected?
Is this patch OK (both for gomp-4_0-branch, and also for trunk?), or
should this rather use something like:

    -if (!INSN_P (probe))
    +if (NOTE_P (probe) && NOTE_KIND (probe) == NOTE_INSN_DELETED)
       continue;

..., or something yet different?

--- gcc/config/nvptx/nvptx.c
+++ gcc/config/nvptx/nvptx.c
@@ -2286,7 +2286,7 @@ nvptx_propagate_unified (rtx_insn *unified)
 {
   rtx_insn *probe = unified;
   rtx cond_reg = SET_DEST (PATTERN (unified));
-  rtx pat;
+  rtx pat = NULL_RTX;
 
   /* Find the comparison.  (We could skip this and simply scan to he
      blocks' terminating branch, if we didn't care for self
@@ -2294,14 +2294,17 @@ nvptx_propagate_unified (rtx_insn *unified)
   for (;;)
     {
       probe = NEXT_INSN (probe);
+      if (!INSN_P (probe))
+	continue;
       pat = PATTERN (probe);
 
       if (GET_CODE (pat) == SET
 	  && GET_RTX_CLASS (GET_CODE (SET_SRC (pat))) == RTX_COMPARE
 	  && XEXP (SET_SRC (pat), 0) == cond_reg)
 	break;
-      gcc_assert (NONJUMP_INSN_P (probe) || !INSN_P (probe));
+      gcc_assert (NONJUMP_INSN_P (probe));
     }
+  gcc_assert (pat != NULL_RTX);
   rtx pred_reg = SET_DEST (pat);
 
   /* Find the branch.  */


Grüße
 Thomas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]