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: the loss of SET_TYPE

From: Gaius Mulley <gaius at glam dot ac dot uk>
To: "Steven Bosscher" <stevenb dot gcc at gmail dot com>
Cc: gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org, nathan at codesourcery dot com, zack at codesourcery dot com
Date: 25 Mar 2006 19:13:36 +0000
Subject: Re: the loss of SET_TYPE
References: <87veu3e6ho.fsf@glam.ac.uk> <571f6b510603250731s5f4b03d8gdb81d5d7b7c4a341@mail.gmail.com>

"Steven Bosscher" <stevenb.gcc@gmail.com> writes:

> On 25 Mar 2006 00:02:43 +0000, Gaius Mulley <gaius@glam.ac.uk> wrote:
> > Pragmatically I guess it is best for me to maintain a reversed patch
> > which can be applied to a gcc-4.1.0 tar ball which reintroduces this
> > TYPE. Any thoughts?
> 
> I think it would be better if you make the SET_TYPE a front-end
> specific tree node, much like e.g. the tcc_type tree codes in
> cp/cp-tree.def.  Then you can use SET_TYPE in the front end, and
> translate the set operations to valid GIMPLE later on when
> gimplifying.

Hi,

thanks for the pointers - yes this does seem a better approach..

regards,
Gaius

References:
- the loss of SET_TYPE
  - From: Gaius Mulley
- Re: the loss of SET_TYPE
  - From: Steven Bosscher

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