[Bug tree-optimization/59757] New: Unexpected VN_TOP in SSCVN

[Bug tree-optimization/59757] New: Unexpected VN_TOP in SSCVN

[joey.ye at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757

            Bug ID: 59757
           Summary: Unexpected VN_TOP in SSCVN
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joey.ye at arm dot com

Created attachment 31796
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31796&action=edit
Reduced test case

target: arm-none-eabi
host: Only Windows (crossbuild with i586-mingw32msvc). The same revision
doesn't fail on Linux
GCC revision: trunk 20141009 and 4.8
Option: -O3

> arm-none-eabi-gcc -O3 foo.c
foo.c: In function 'univision_ug2828gfeff01_init':
foo.c:119:1: internal compiler error: tree check: expected ssa_name, have
var_de
cl in vn_reference_lookup_2, at tree-ssa-sccvn.c:1497
 univision_ug2828gfeff01_init(CTL_GFX_SEP_DRIVER_t *d, int depth)
 ^

foo.c:119:1: internal compiler error: Segmentation fault

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[joey.ye at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757

--- Comment #1 from Joey Ye <joey.ye at arm dot com> ---
foo.c: In function 'univision_ug2828gfeff01_init':
foo.c:119:1: internal compiler error: tree check: expected ssa_name, have
var_de
cl in vn_reference_compute_hash, at tree-ssa-sccvn.c:631
 univision_ug2828gfeff01_init(CTL_GFX_SEP_DRIVER_t *d, int depth)

Traced to SSCVN:
Breakpoint 1, vn_reference_compute_hash (vr1=0x798fa94)
    at /xxx/src/gcc/gcc/tree-ssa-sccvn.c:598
598     in /xxx/src/gcc/gcc/tree-ssa-sccvn.c

Backtrace is 
vn_reference_lookup

(gdb) call debug_tree(vr1->vuse)
 <var_decl 0x8fe4ba0 vn_top.15
    type <void_type 0x89c08a0 void VOID
        align 8 symtab 0 alias set -1 canonical type 0x89c08a0
        pointer_to_this <pointer_type 0x89c0900>>
    used ignored VOID file foo.c line 119 col 1
    align 8>

(gdb) call debug_tree(VN_TOP)
 <var_decl 0x8fe4ba0 vn_top.15
    type <void_type 0x89c08a0 void VOID
        align 8 symtab 0 alias set -1 canonical type 0x89c08a0
        pointer_to_this <pointer_type 0x89c0900>>
    used ignored VOID file foo.c line 119 col 1
    align 8>

For some reason vr1->vuse is VN_TOP, which is unexpected. But I couldn't go
further without understanding SCCVN.

Anyone can help?

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Cannot reproduce with cross from x86_64-linux (as you said ...).  So it's not
easy to help here.

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Cannot reproduce with cross from x86_64-linux (as you said ...).  So it's not
> easy to help here.

Try from i586-linux with gcc/g++ -m32.

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #3)
> > Cannot reproduce with cross from x86_64-linux (as you said ...).  So it's not
> > easy to help here.
> 
> Try from i586-linux with gcc/g++ -m32.

Doesn't help.

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[joey.ye at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757

--- Comment #5 from Joey Ye <joey.ye at arm dot com> ---
Here are some debug and log that might help to investigate.

Following one is suspecious to me, .MEM_18 is said to be defined a stmt that
doesn't look like it should do
(gdb) call debug_tree((*cfun->gimple_df->ssa_names).m_vecdata[18] )
 <ssa_name 0x8fcacf8
    type <void_type 0x89c08a0 void VOID
        align 8 symtab 0 alias set -1 canonical type 0x89c08a0
        pointer_to_this <pointer_type 0x89c0900>>
    visited var <var_decl 0x8fcc720 .MEM>def_stmt _11 = _10 (258);

    version 18>

dump.pre:
SCC consists of: .MEM_18
SCC consists of: _12
Value numbering _12 stmt = _12 = d_2(D)->core.get_parameter;
<then crash>

Last good dump:
univision_ug2828gfeff01_init (struct CTL_GFX_SEP_DRIVER_t * d, int depth)
{
  struct CTL_GFX_DRIVER_t * _7;
  long int _9;
  long int (*<Td17>) (int) _10;
  long int _11;
  long int (*<Td17>) (int) _12;
  long int _13;

  <bb 2>:
  d_2(D)->core.get_parameter = univision_ug2828gfeff01_get_parameter;
  _7 = &d_2(D)->core;
  ctl_gfx_driver = _7;
  MEM[(struct CTL_GFX_DRIVER_t *)d_2(D)].draw_pixel = 0B;
  _9 = univision_ug2828gfeff01_get_parameter (258);
  if (_9 == 8)
    goto <bb 3>;
  else
    goto <bb 4>;

  <bb 3>:
  d_2(D)->set_bounding = sep_set_bounding_8b;
  goto <bb 9>;

  <bb 4>:
  _10 = d_2(D)->core.get_parameter;
  _11 = _10 (258);
  if (_11 == 16)
    goto <bb 5>;
  else
    goto <bb 6>;

  <bb 5>:
  d_2(D)->set_bounding = sep_set_bounding_16b;
  goto <bb 9>;

  <bb 6>:
  _12 = d_2(D)->core.get_parameter;
  _13 = _12 (512);
  if (_13 > 255)
    goto <bb 7>;
  else
    goto <bb 8>;

  <bb 7>:
  d_2(D)->set_bounding = sep_set_bounding_16b;
  goto <bb 9>;

  <bb 8>:
  d_2(D)->set_bounding = sep_set_bounding_8b;

  <bb 9>:
  return;

}

Any hint to continue investigating?

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 13 Jan 2014, joey.ye at arm dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757
> 
> --- Comment #5 from Joey Ye <joey.ye at arm dot com> ---
> Here are some debug and log that might help to investigate.
> 
> Following one is suspecious to me, .MEM_18 is said to be defined a stmt that
> doesn't look like it should do
> (gdb) call debug_tree((*cfun->gimple_df->ssa_names).m_vecdata[18] )
>  <ssa_name 0x8fcacf8
>     type <void_type 0x89c08a0 void VOID
>         align 8 symtab 0 alias set -1 canonical type 0x89c08a0
>         pointer_to_this <pointer_type 0x89c0900>>
>     visited var <var_decl 0x8fcc720 .MEM>def_stmt _11 = _10 (258);
> 
>     version 18>

This is an indirect call which clobbers memory and thus has to
define .MEM.

> dump.pre:
> SCC consists of: .MEM_18

.MEM_18 should get a value-number (.MEM_18 itself) during
processing of this stmt.  I suppose that the value-number of
_10 is not _10 but a const/pure function decl.  You can
put a breakpoint on visit_use if use->base.u.version == 18
and follow what happens.  It seems that there must be a path
in its is_gimple_call () handling where it fails to assign
a value-number to the virtual operand.

> SCC consists of: _12
> Value numbering _12 stmt = _12 = d_2(D)->core.get_parameter;
> <then crash>
> 
> Last good dump:
> univision_ug2828gfeff01_init (struct CTL_GFX_SEP_DRIVER_t * d, int depth)
> {
>   struct CTL_GFX_DRIVER_t * _7;
>   long int _9;
>   long int (*<Td17>) (int) _10;
>   long int _11;
>   long int (*<Td17>) (int) _12;
>   long int _13;
> 
>   <bb 2>:
>   d_2(D)->core.get_parameter = univision_ug2828gfeff01_get_parameter;
>   _7 = &d_2(D)->core;
>   ctl_gfx_driver = _7;
>   MEM[(struct CTL_GFX_DRIVER_t *)d_2(D)].draw_pixel = 0B;
>   _9 = univision_ug2828gfeff01_get_parameter (258);
>   if (_9 == 8)
>     goto <bb 3>;
>   else
>     goto <bb 4>;
> 
>   <bb 3>:
>   d_2(D)->set_bounding = sep_set_bounding_8b;
>   goto <bb 9>;
> 
>   <bb 4>:
>   _10 = d_2(D)->core.get_parameter;
>   _11 = _10 (258);
>   if (_11 == 16)
>     goto <bb 5>;
>   else
>     goto <bb 6>;
> 
>   <bb 5>:
>   d_2(D)->set_bounding = sep_set_bounding_16b;
>   goto <bb 9>;
> 
>   <bb 6>:
>   _12 = d_2(D)->core.get_parameter;
>   _13 = _12 (512);
>   if (_13 > 255)
>     goto <bb 7>;
>   else
>     goto <bb 8>;
> 
>   <bb 7>:
>   d_2(D)->set_bounding = sep_set_bounding_16b;
>   goto <bb 9>;
> 
>   <bb 8>:
>   d_2(D)->set_bounding = sep_set_bounding_8b;
> 
>   <bb 9>:
>   return;
> 
> }
> 
> Any hint to continue investigating?
> 
>

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
That is,

Index: gcc/tree-ssa-sccvn.c
===================================================================
--- gcc/tree-ssa-sccvn.c        (revision 206576)
+++ gcc/tree-ssa-sccvn.c        (working copy)
@@ -3605,6 +3605,7 @@ visit_use (tree use)
        changed = defs_to_varying (stmt);
     }
  done:
+  gcc_assert (!virtual_operand_p (use) || SSA_VAL (use) != VN_TOP);
   return changed;
 }

should help catching the bug.

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[joey.ye at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757

Joey Ye <joey.ye at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Joey Ye <joey.ye at arm dot com> ---
This is most likely a bug in mingw32 build for GCC 4.2.1, which is the compiler
that I used to build GCC running on Windows. If GCC is built with -O0 it passes
without this ICE.

Switching to later version of mingw32 tools solves it.