Re: Alias analysis or DSE problem?

[Justin Seyster <jrseys at gmail dot com>]

You're right: that was exactly the difference.  It turns out I was
setting the third and fourth operands in the ARRAY_REF to what I
thought were sensible values.  Setting them to NULL instead made the
ADDR_EXPR satisfy is_gimple_min_invariant() and fixed the whole mess.

Thanks again for looking at this.
        --Justin

On Tue, Oct 20, 2009 at 5:18 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Oct 20, 2009 at 1:34 AM, Justin Seyster <jrseys@gmail.com> wrote:
>> Thanks a lot for the help! ?It looks like creating a temporary
>> took care of it.
>>
>> On Sat, Oct 17, 2009 at 7:41 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> I think the call you insert is not of valid gimple form - an address
>>> argument has to fulfill the is_gimple_min_invariant() predicate.
>>> Thus I suspect you have something like &ptr->field in there which
>>> needs a temporary.
>>
>> That was it. ?Actually, the TREE was of the form
>> ADDR_EXPR(ARRAY_REF(STRING_CST)), which does not satisfy
>> is_gimple_min_invariant().
>>
>> The strange thing is, I copied that structure verbatim from
>> unmodified GCC. ?I'm trying to insert a call that looks like:
>>
>> foo("some string constant");
>>
>> If I put that function call in a simple C program and dump out
>> the resulting GIMPLE, it gives me the ADDR_EXPR that was causing
>> problems in refs_may_alias_p_1().
>>
>> Does anyone know why that structure is ok in the contexts that
>> GCC is using it but not in the context that my plug-in uses it
>> in?
>
> If your "string" does not satisfy is_gimple_min_invariant then
> it is not of the form you mentioned above. ?A wild guess would
> be that you have the 2nd or 3rd operand of the ARRAY_REF set.
>
> Richard.
>
>> ? ? ? ?--Justin
>>
>