This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?


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

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> 2011-03-10 13:07:16 UTC ---
On Thu, 10 Mar 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
> 
> --- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-03-10 13:04:17 UTC ---
> > That would work, too.  You see no problem with a NULL operand 3
> > of array-refs?  If you create an array with a variable lower bound,
> > take its address, convert it to pointer to element type and
> > dereference that, would it expand ok if it does not have the
> > element size set properly?  At least get_inner_reference seems to
> > unconditionally multiply with array_ref_element_size () * index,
> > and array_ref_element_size () does not work for variable-size types
> > if the array-ref doesn't have the gimplified value.
> 
> Isn't gimplification supposed to populate this operand #3?

Ugh, yeah it does - but, do we really rely on this?  Probably yes ...
so setting operand #2 in the folder is not necessary either.

Ok, I'll go with the in_gimple_form check.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]