Crash at gimple_code(gimple* )

Shuai Wang wangshuai901@gmail.com
Wed Jul 15 13:49:23 GMT 2020


Hello!

Thank you very much. I use the following statement to check and I confirm
that it's not SSA_NAME:

if (TREE_CODE(operand) != SSA_NAME) return;

But considering the following code snippet:

_313 = _312 + 2147450880;
_314 = (signed char *) _313;
_315 = **_314*;                         // _314 is NOT a SSA_NAME

I was using the SSA_NAME_DEF_STMT here and there but right now since it
does not work, how can I backwardly track the dependency of the above code
snippet? Basically given _314, I would like to backwardly collect _313,
_312, ..., until constructing the entire data dependency of _314...? Thanks
a lot!

Best,
Shuai

On Wed, Jul 15, 2020 at 6:49 PM Martin Jambor <mjambor@suse.cz> wrote:

> Hi,
>
> On Wed, Jul 15 2020, Shuai Wang via Gcc wrote:
> > Hello,
> >
> > I am using the following code to iterate different gimple statements:
> >
> > ...
> >  gimple* stmt = gsi_stmt(gsi);
> > if (gimple_assign_load_p(stmt)) {
> >      tree rhs = gimple_assign_rhs1 (stmt);
> >      if (!rhs) return;
> >       gimple* def_stmt = SSA_NAME_DEF_STMT(rhs);
>
> The RHS of a gimple load can never be an SSA_NAME (just look at the
> source of gimple_assign_load_p), so you cannot use SSA_NAME_DEF_STMT
> with it.  It's usually a VAR_DECL (or PARM_DECL) or MEM_REF which
> however can be buried within arbitrarily complex "handled_component"
> (see handled_component_p), i.e. ARRAY_REFs, COMPONENT_REFs and the like.
>
> >       if (!def_stmt) return;
> >
> >      switch (gimple_code (def_stmt)) {
> >          ....
> >      }
> > }
> >
> > While the above code works smoothly for most of the cases, to my
> surprise,
> > the following statement (pointed by gsi) would cause a crash at
> > gimple_code(def_stmt):
> >
> > stderr.9_1 = stderr;
>
> the RHS is a VAR_DECL here.
>
> Martin
>


More information about the Gcc mailing list