From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-440204-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 23948 invoked by alias); 13 Jan 2014 11:55:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 23899 invoked by uid 55); 13 Jan 2014 11:55:19 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN
Date: Mon, 13 Jan 2014 11:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59757-4-FRtKaK8X5l@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59757-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59757-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg01346.txt.bz2

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?
> 
>