From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21377 invoked by alias); 26 Nov 2001 21:29:47 -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 21342 invoked from network); 26 Nov 2001 21:29:46 -0000 Received: from unknown (HELO mail.wrs.com) (147.11.1.11) by hostedprojects.ges.redhat.com with SMTP; 26 Nov 2001 21:29:46 -0000 Received: from kankakee.wrs.com (kankakee [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA29195; Mon, 26 Nov 2001 13:28:20 -0800 (PST) From: mike stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.3+Sun/8.9.0) id NAA16653; Mon, 26 Nov 2001 13:29:00 -0800 (PST) Date: Sat, 17 Nov 2001 11:23:00 -0000 Message-Id: <200111262129.NAA16653@kankakee.wrs.com> To: kenner@vlsi1.ultra.nyu.edu, neil@daikokuya.demon.co.uk Subject: Re: ICE in change_address at emit_rtl.c Cc: gcc@gcc.gnu.org X-SW-Source: 2001-11/txt/msg00782.txt.bz2 > Date: Sun, 25 Nov 01 09:23:28 EST > From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) > To: neil@daikokuya.demon.co.uk > Cc: gcc@gcc.gnu.org > And why can't you look inside a temporary the same way you look inside > a SAVE_EXPR? > Right now we have no mechanism for doing so. > However, my question is what do we gain by removing SAVE_EXPR if we add > temporaries that have exactly the same semantics? If you do everything > that SAVE_EXPR can do, all you've done is renamed it! If you increase the likely hood that the compiler will just work in the face of changing code, and random maintenance and decrease the maintenance code, and make the code easier to read and understand, then you gained more, than just renaming it, you've improved it. It is reasonable to find a way to `improve' SAVE_EXPR. Check out UNSAVE_EXPR, and the `grossness' of it. It is truely worth eliminating by design. Unfortunately to get rid of it, you need to revamp SAVE_EXPR. From mboxrd@z Thu Jan 1 00:00:00 1970 From: mike stump To: kenner@vlsi1.ultra.nyu.edu, neil@daikokuya.demon.co.uk Cc: gcc@gcc.gnu.org Subject: Re: ICE in change_address at emit_rtl.c Date: Mon, 26 Nov 2001 13:29:00 -0000 Message-ID: <200111262129.NAA16653@kankakee.wrs.com> X-SW-Source: 2001-11/msg01286.html Message-ID: <20011126132900.WRwaFnzizMOqLAI7o-TKAhmWnkyayK7AHKgyKytFrEc@z> > Date: Sun, 25 Nov 01 09:23:28 EST > From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) > To: neil@daikokuya.demon.co.uk > Cc: gcc@gcc.gnu.org > And why can't you look inside a temporary the same way you look inside > a SAVE_EXPR? > Right now we have no mechanism for doing so. > However, my question is what do we gain by removing SAVE_EXPR if we add > temporaries that have exactly the same semantics? If you do everything > that SAVE_EXPR can do, all you've done is renamed it! If you increase the likely hood that the compiler will just work in the face of changing code, and random maintenance and decrease the maintenance code, and make the code easier to read and understand, then you gained more, than just renaming it, you've improved it. It is reasonable to find a way to `improve' SAVE_EXPR. Check out UNSAVE_EXPR, and the `grossness' of it. It is truely worth eliminating by design. Unfortunately to get rid of it, you need to revamp SAVE_EXPR.