This is the mail archive of the
gcc@gcc.gnu.org
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.9000306@naturalbridge.com> <84fc9c000608111344l3cc4b9f0w97f104da6ed5b7ad@mail.gmail.com> <44DCEDF1.9010902@naturalbridge.com> <84fc9c000608111356n6bd522d5gd349007fdcb0cd1b@mail.gmail.com> <44DCF0A0.1060005@naturalbridge.com> <44DF6702.4060901@codesourcery.com> <1155495354.16382.65.camel@fuel98.slc.redhat.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
> pass.
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.
Thanks,
Andrew Pinski