This is the mail archive of the
mailing list for the GCC project.
Re: type consistency of gimple
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: law at redhat dot com
- Cc: Mark Mitchell <mark at codesourcery dot com>, Kenneth Zadeck <zadeck at naturalbridge dot com>, Richard Guenther <richard dot guenther at gmail dot com>, GCC <gcc at gcc dot gnu dot org>, "Novillo, Diego" <dnovillo at redhat dot com>, "Hubicha, Jan" <jh at suse dot cz>, "Edelsohn, David" <dje at watson dot ibm dot com>
- Date: Sun, 13 Aug 2006 12:07:08 -0700
- Subject: Re: type consistency of gimple
- References: <44DCEAAA.email@example.com> <firstname.lastname@example.org> <44DCEDF1.email@example.com> <firstname.lastname@example.org> <44DCF0A0.email@example.com> <44DF6702.firstname.lastname@example.org> <email@example.com>
On Sun, 2006-08-13 at 12:55 -0600, Jeffrey Law wrote:
> Thus the existence of some implicit type conversions. IIRC the
> places where these occur or occurred at one time or we pondered
> allowing are:
> 1. MODIFY_EXPRs where the RHS can be implicitly converted to the
> type of the LHS and the types do not vary in size/mode or
> signedness. DOM probably makes more use of this than any
This still happens today.
> 2. I think we sometimes implicitly convert COMPONENT_REF expressions.
> ie, the field we're accessing has some type X, but we want a result
> in some other type Y. Under certain circumstances we may access
> the field in type Y. I believe this occurs during gimplification.
This happens less and less. Most of the problems with this are all
related to the front-end rather than the middle-end producing the trees
wrongly. I have at least two bugs still out on the C++ front-end for
producing a cast instead of ADDR_EXPR/COMPONENT_REF.
PR 19816 and 19817.