Re: SRA generates uninitialized var use

[Richard Guenther <richard.guenther@gmail.com>]

On Mon, Jun 20, 2011 at 6:15 PM, Xinliang David Li <davidxl@google.com> wrote:
> It is used to indicate the fact the var decl needs to have a memory
> home (addressable) -- is there another way to do this? this is to
> avoid the following situation:
>
> 1) after SRA before update SSA, the IR looks like:
>
>   MEM[.... &SR_123] = ...
>
>   other_var = SR_123;   <---- (x)
>
>
> In this case, SR_123 is not of aggregate type, and it is not
> addressable, update_ssa won't assign a VUSE for (x), leading to

The point is, SRA should never have created the above

  MEM[.... &SR_123] = ...

Martin, why would it even create new _memory_ backed decls?

Richard.

> 2) final IR after SRA:
>
>   MEM[..., &SR_123] = ..
>   other_var = SR_123_yyy(D);
>
>
> David
>
> On Mon, Jun 20, 2011 at 4:13 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Sat, Jun 18, 2011 at 10:56 AM, Xinliang David Li <davidxl@google.com> wrote:
>>> Compiling the test case in the patch with -O2 -m32 without the fix,
>>> the program will abort. The problem is a var decl whose address is
>>> taken is not marked as addressable leading to bad SSA update (missing
>>> VUSE).  (the triaging used the the .after and .after_cleanup dump diff
>>> and found the problem).
>>>
>>> the test is on going. Ok after testing?
>>
>> That doesn't make sense.  SRA shouldn't generate anything that has
>> its address taken.  So, where do we take its address?
>>
>> Richard.
>>
>>> Thanks,
>>>
>>> David
>>>
>>
>