This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Patch: stab info for const fields
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: mark at codesourcery dot com, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Thu, 31 Oct 2002 15:14:51 -0800
- Subject: Re: Patch: stab info for const fields
- References: <10210312234.AA02770@vlsi1.ultra.nyu.edu>
On Thu, Oct 31, 2002 at 05:34:37PM -0500, Richard Kenner wrote:
> So the idea is that we allow "compatible" types on the two operands and
> the result of a PLUS_EXPR, but they are not required to all be the same?
> We've never really been clear on that and there are three possibilities:
>
> (1) The types are exactly the same.
> (2) TYPE_MAIN_VARIANT of the types are the same.
> (3) The types are "compatible" (to be defined later).
>
> I've argued for (1) in the past and continue to do so. Is the above
> arguing for (2) or (3)?
Slight variant of (3), as I understand it:
(3a) The types are "compatible", which is a term with a precise
but language-specific definition; consult the relevant standard.
The actual implementation I would suggest for this is: Language
specific code is responsible for enforcing all relevant constraints on
type compatibility. The language independent optimizers and lowerers
assume that if the front end provided
<plus_expr type <integer_type A>
arg 0 <expression type <integer_type B>>
arg 1 <expression type <integer_type C>>
>
that it is to convert integer_types B and C to A before performing the
addition. If this cannot be accomplished with a notional NOP_EXPR the
tree is invalid (ICE on detection).
zw