This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix tree-data-ref.c ICE on VIEW_CONVERT_EXPR<type>(0) (PR tree-optimization/33856)
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Jakub Jelinek" <jakub at redhat dot com>
- Cc: "Sebastian Pop" <spop at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 27 Oct 2007 18:33:55 +0200
- Subject: Re: [PATCH] Fix tree-data-ref.c ICE on VIEW_CONVERT_EXPR<type>(0) (PR tree-optimization/33856)
- References: <20071027161002.GX5451@devserv.devel.redhat.com>
On 10/27/07, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> VIEW_CONVERT_EXPR<some_type>(0), while REFERENCE_CLASS_P, doesn't have any
> base address and is really constant.
> In get_references_in_stmt any operand which is DECL_P or REFERENCE_CLASS_P
> is added to the references vector, but later on when for each references
> vector entry it calls create_data_ref (but in other cases too)
> get_base_address is called on it and expected to return non-NULL.
> Either we handle get_base_address returning NULL in dr_analyze_alias
> and disjoint_objects_p (and additionally need to analyze dr_analyze_indices
> etc.), or we don't consider a reference to constant as a reference,
> which is what the attached patch does.
>
> Regtested on x86_64-linux, ok for trunk?
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
not folding this case is appropriate so we can address this during next
stage1.
Does this PR happen because key is uninitialized?
Otherwise I guess this is ok.
Thanks,
Richard.
> 2007-10-27 Jakub Jelinek <jakub@redhat.com>
>
> PR tree-optimization/33856
> * tree-data-ref.c (get_references_in_stmt): Don't add
> REFERENCE_CLASS_P trees to references vector if get_base_address
> returns NULL on them.
>
> * gcc.c-torture/compile/20071027-1.c: New test.