This is the mail archive of the gcc-patches@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]

Re: [PATCH] Fix tree-data-ref.c ICE on VIEW_CONVERT_EXPR<type>(0) (PR tree-optimization/33856)


On 10/27/07, Jakub Jelinek <jakub@redhat.com> wrote:
> On Sat, Oct 27, 2007 at 06:33:55PM +0200, Richard Guenther wrote:
> > While there might be cases we (currently) do not fold
> > VIEW_CONVERT_EXPR<>(cst), did you look at why we do not in this
> > particular case (what's some_type?).  Possibly a separate PR for
>
> Yes.  some_type in this case is a RECORD_TYPE, and folding VIEW_CONVERT_EXPR
> (particularly in native_interpret_expr) handles only integral, floating
> and vector types.  Not sure if it is a good idea to change that (or perhaps
> just special case 0 there and turn that into a zero element CONSTRUCTOR of
> the corresponding type).  Or perhaps SRA could avoid creating
> VIEW_CONVERT_EXPR for RECORD_TYPE/UNION_TYPE.
>
> > not folding this case is appropriate so we can address this during next
> > stage1.
> >
> > Does this PR happen because key is uninitialized?
>
> Yes, that VIEW_CONVERT_EXPR is created during early SRA (and it a struct
> of two ints, so on LP64 it is the same size as long)

Interesting.  Why does SRA bother to initialize uninitialized fields?

Richard.


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