From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18123 invoked by alias); 4 Feb 2004 16:14:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 18111 invoked from network); 4 Feb 2004 16:14:51 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 4 Feb 2004 16:14:51 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA01497; Wed, 4 Feb 04 11:17:24 EST Date: Wed, 04 Feb 2004 16:14:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10402041617.AA01497@vlsi1.ultra.nyu.edu> To: matz@suse.de Subject: Re: What to remove after tree-ssa is merged? Cc: gcc@gcc.gnu.org X-SW-Source: 2004-02/txt/msg00269.txt.bz2 Probably I'm asking the wrong thing because I'm in turn unsure, where exactly P_E is used inside types. Within the expressions for TYPE_MIN_VALUE TYPE_MAX_VALUE DECL_FIELD_OFFSET TYPE_SIZE TYPE_SIZE_UNIT The example you gave (as I understood it) happens to actually use the P_E only in the context of an expression (a COMPONENT_REF in fact), also if the P_E expression was only found by looking into the type of the bounded array. Looking into a type, yes, but I'm not sure what you mean by "bounded array". So in that example the P_E is used in expressions, so they could be lowered to trees not containing P_E (this involves probably making some element references more explicit). But you don't have the *object* to make it more explicit when it's inside the type. That's the whole point: it applies to every *object* of the type. To that question you then mentioned P_E inside types, but they should only matter for type comparing or in context of expressions AFAICS. the latter can be done with the above frontend specific lowering. No, because it has to be done by the code that computes sizes and offsets in the middle end.