Crash at gimple_code(gimple* )

[Martin Jambor]

Hi,

On Wed, Jul 15 2020, Shuai Wang wrote:
> 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!

_314 almost certainly is an SSA_NAME, *_314 is not (note that star), it
is a MEM_REF (as far as I can tell from your email).
TREE_OPERAND (gimple_assign_rhs1 (stmt)) will give you the _314 SSA_NAME
on which you can use SSA_NAME_DEF_STMT.

When in doubt, debug_tree (callable also from within gdb) is your friend.

Martin


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