[Bug tree-optimization/22615] [4.1 Regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2858

["dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-08-11 12:55 -------
Subject: Re:  [4.1 Regression] ICE in
	first_vi_for_offset, at tree-ssa-structalias.c:2858

On Thu, 2005-08-11 at 10:44 +0000, rguenth at gcc dot gnu dot org wrote:
> ------- Additional Comments From rguenth at gcc dot gnu dot org  2005-08-11 10:44 -------
> We inline all and get
> 
> void bar() ()
> {
>   char & D.1777;
>   struct B * D.1776;
>   char & D.1773;
>   union C D.1772;
> 
> <bb 0>:
>   D.1772.p = &a;
>   D.1776_5 = D.1772.q;
>   D.1777_6 = &D.1776_5->d;
>   D.1773_7 = D.1777_6;
>   *D.1773_7 = 0;
>   return;
> 
> }
> 
> where we access the padding between c and i in struct A through an
> object of type B.  This must be invalid code.  Even if it is, the
> gcc_unreachable () is probably not a good idea - Danny, how should
> we deal with this?  Ignore references to padding and just return
> NULL from first_vi_for_offset?

I know what to do here. I've just been waiting as long as possible to
remove the assert because it also catches real bugs.
I actually plan on removing it today, and have bootstrapped and tested a
patch to do so.

> 
> There's a similar problem in get_constraint_for_component_ref which
> I hit with array-aliasing and work-around by

> 
> *************** get_constraint_for_component_ref (tree t
> *** 2075,2082 ****
>             }
>           /* assert that we found *some* field there. The user couldn't be
>              accessing *only* padding.  */
> !
> !         gcc_assert (curr);
>         }
>         else
>         if (dump_file && (dump_flags & TDF_DETAILS))
> --- 2076,2084 ----
>             }
>           /* assert that we found *some* field there. The user couldn't be
>              accessing *only* padding.  */
> !         /* Still the user could access one past the end of an array
> !            embedded in a struct resulting in accessing *only* padding.  */
> !         /* gcc_assert (curr); */

You are right, but this can only occur with your patch, since it
wouldn't have had fields before, and thus it would have overlapped with
the actual variable, giving the right answer.  :)







-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22615