SRA generates uninitialized var use

SRA generates uninitialized var use

[Xinliang David Li]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

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?

Thanks,

David

[-- Attachment #2: sra_bug.p --]
[-- Type: application/octet-stream, Size: 3317 bytes --]

2011-06-18  David Li  <davidxl@google.com>

	* tree-sra.c (generate_subtree_copies): Mark var_decl
	addressable.


2011-06-18  David Li  <davidxl@google.com>
	* testsuite/g++.dg/tree-ssa/sra_bug.C: New test.

Index: tree-sra.c
===================================================================
--- tree-sra.c	(revision 175051)
+++ tree-sra.c	(working copy)
@@ -2280,6 +2280,8 @@ generate_subtree_copies (struct access *
 	  expr = build_ref_for_model (loc, agg, access->offset - top_offset,
 				      access, gsi, insert_after);
 
+          if (TREE_CODE (agg) == VAR_DECL)
+	    TREE_ADDRESSABLE (agg) = 1;
 	  if (write)
 	    {
 	      if (access->grp_partial_lhs)
Index: testsuite/g++.dg/tree-ssa/sra_bug.C
===================================================================
--- testsuite/g++.dg/tree-ssa/sra_bug.C	(revision 0)
+++ testsuite/g++.dg/tree-ssa/sra_bug.C	(revision 0)
@@ -0,0 +1,90 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+#include <stdio.h>
+#include <stdlib.h>
+typedef int int32;
+typedef unsigned int uint32;
+typedef unsigned long long uint64;
+typedef short int16;
+
+class Tp {
+ public:
+  Tp(int, const int segment, const int index) __attribute__((noinline));
+
+  inline bool operator==(const Tp& other) const;
+  inline bool operator!=(const Tp& other) const;
+  int GetType() const { return type_; }
+  int GetSegment() const { return segment_; }
+  int GetIndex() const { return index_; }
+ private:
+  inline static bool IsValidSegment(const int segment);
+  static const int kSegmentBits = 28;
+  static const int kTypeBits = 4;
+  static const int kMaxSegment = (1 << kSegmentBits) - 1;
+
+  union {
+
+    struct {
+      int32 index_;
+      uint32 segment_ : kSegmentBits;
+      uint32 type_ : kTypeBits;
+    };
+    struct {
+      int32 dummy_;
+      uint32 type_and_segment_;
+    };
+    uint64 value_;
+  };
+};
+
+Tp::Tp(int t, const int segment, const int index)
+ : index_(index), segment_(segment), type_(t) {}
+
+inline bool Tp::operator==(const Tp& other) const {
+  return value_ == other.value_;
+}
+inline bool Tp::operator!=(const Tp& other) const {
+  return value_ != other.value_;
+}
+
+class Range {
+ public:
+  inline Range(const Tp& position, const int count) __attribute__((always_inline));
+  inline Tp GetBeginTokenPosition() const;
+  inline Tp GetEndTokenPosition() const;
+ private:
+  Tp position_;
+  int count_;
+  int16 begin_index_;
+  int16 end_index_;
+};
+
+inline Range::Range(const Tp& position,
+                    const int count)
+    : position_(position), count_(count), begin_index_(0), end_index_(0)
+    { }
+
+inline Tp Range::GetBeginTokenPosition() const {
+  return position_;
+}
+inline Tp Range::GetEndTokenPosition() const {
+  return Tp(position_.GetType(), position_.GetSegment(),
+            position_.GetIndex() + count_);
+}
+
+int main ()
+{
+  Range range(Tp(0, 0, 3), 0);
+  if (!(range.GetBeginTokenPosition() == Tp(0, 0, 3)))
+    {
+      fprintf (stderr, " FAILED 1!!!!\n");
+      abort ();
+    }
+  if (!(range.GetEndTokenPosition() == Tp(0, 0, 3)))
+    {
+      fprintf (stderr, "FAILED 2\n");
+      abort();
+    }
+  return 0;
+}

Property changes on: testsuite/g++.dg/tree-ssa/sra_bug.C
___________________________________________________________________
Added: svn:executable
   + *

Re: SRA generates uninitialized var use

[Xinliang David Li]

Bootstrap and tested on linux/x86_64.

Ok for trunk?

David


On Sat, Jun 18, 2011 at 1: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?
>
> Thanks,
>
> David
>

Re: SRA generates uninitialized var use

[Richard Guenther]

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
>

Re: SRA generates uninitialized var use

[Xinliang David Li]

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

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

Re: SRA generates uninitialized var use

[Richard Guenther]

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

Re: SRA generates uninitialized var use

[Xinliang David Li]

Good point -- but why does SRA have to be so complicated? If it just
do structure expansion and let subsequent phases to clean it up, would
it be simpler? Anyway this is off the topic.

Thanks,

David


On Mon, Jun 20, 2011 at 1:47 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> 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
>>>>
>>>
>>
>

Re: SRA generates uninitialized var use

[Richard Guenther]

On Tue, Jun 21, 2011 at 1:28 AM, Xinliang David Li <davidxl@google.com> wrote:
> Good point -- but why does SRA have to be so complicated? If it just
> do structure expansion and let subsequent phases to clean it up, would
> it be simpler? Anyway this is off the topic.

Well, it's certainly non-optimal to insert new memory backed variables
to get rid of memory backed variables ...

Richard.

> Thanks,
>
> David
>
>
> On Mon, Jun 20, 2011 at 1:47 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> 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
>>>>>
>>>>
>>>
>>
>

Re: SRA generates uninitialized var use

[Richard Guenther]

On Tue, Jun 21, 2011 at 5:51 PM, Xinliang David Li <davidxl@google.com> wrote:
> On Tue, Jun 21, 2011 at 1:42 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Tue, Jun 21, 2011 at 1:28 AM, Xinliang David Li <davidxl@google.com> wrote:
>>> Good point -- but why does SRA have to be so complicated? If it just
>>> do structure expansion and let subsequent phases to clean it up, would
>>> it be simpler? Anyway this is off the topic.
>>
>> Well, it's certainly non-optimal to insert new memory backed variables
>> to get rid of memory backed variables ...
>>
>
> Yes, in the current way it is not optimal.
>
> Before that problem is resolved, is the simple patch ok for trunk? The
> non-optimal code issue can be tracked with a different bug.

No, it's not a proper fix.

Richard.

> Thanks,
>
> David
>
>> Richard.
>>
>>> Thanks,
>>>
>>> David
>>>
>>>
>>> On Mon, Jun 20, 2011 at 1:47 PM, Richard Guenther
>>> <richard.guenther@gmail.com> wrote:
>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: SRA generates uninitialized var use

[Xinliang David Li]

On Tue, Jun 21, 2011 at 1:42 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Jun 21, 2011 at 1:28 AM, Xinliang David Li <davidxl@google.com> wrote:
>> Good point -- but why does SRA have to be so complicated? If it just
>> do structure expansion and let subsequent phases to clean it up, would
>> it be simpler? Anyway this is off the topic.
>
> Well, it's certainly non-optimal to insert new memory backed variables
> to get rid of memory backed variables ...
>

Yes, in the current way it is not optimal.

Before that problem is resolved, is the simple patch ok for trunk? The
non-optimal code issue can be tracked with a different bug.

Thanks,

David

> Richard.
>
>> Thanks,
>>
>> David
>>
>>
>> On Mon, Jun 20, 2011 at 1:47 PM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: SRA generates uninitialized var use

[Martin Jambor]

Hi,

On Tue, Jun 21, 2011 at 06:08:27PM +0200, Richard Guenther wrote:
> On Tue, Jun 21, 2011 at 5:51 PM, Xinliang David Li <davidxl@google.com> wrote:
> > On Tue, Jun 21, 2011 at 1:42 AM, Richard Guenther
> > <richard.guenther@gmail.com> wrote:
> >> On Tue, Jun 21, 2011 at 1:28 AM, Xinliang David Li <davidxl@google.com> wrote:
> >>> Good point -- but why does SRA have to be so complicated? If it just
> >>> do structure expansion and let subsequent phases to clean it up, would
> >>> it be simpler? Anyway this is off the topic.
> >>
> >> Well, it's certainly non-optimal to insert new memory backed variables
> >> to get rid of memory backed variables ...
> >>
> >
> > Yes, in the current way it is not optimal.
> >
> > Before that problem is resolved, is the simple patch ok for trunk? The
> > non-optimal code issue can be tracked with a different bug.
> 
> No, it's not a proper fix.

Just for the record, I am aware of this, have managed to reproduce it
and it is a high priority task for me.  I'm just still overwhelmed by
email and other backlog from the GCC Gathering (extended) weekend and
so a bit less responsive than usual.

Martin


> 
> Richard.
> 
> > Thanks,
> >
> > David
> >
> >> Richard.
> >>
> >>> Thanks,
> >>>
> >>> David
> >>>
> >>>
> >>> On Mon, Jun 20, 2011 at 1:47 PM, Richard Guenther
> >>> <richard.guenther@gmail.com> wrote:
> >>>> 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
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >

Re: SRA generates uninitialized var use

[Martin Jambor]

Hi,

On Mon, Jun 20, 2011 at 10:47:58PM +0200, Richard Guenther wrote:
> 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?

This is now PR 49516.  I will submit a patch later today after
bootstrapping and testing it.

Martin


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