From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16100 invoked by alias); 31 Jan 2003 10:56:15 -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 16093 invoked from network); 31 Jan 2003 10:56:14 -0000 Received: from unknown (HELO kanga.comsys.se) (62.95.120.145) by 172.16.49.205 with SMTP; 31 Jan 2003 10:56:14 -0000 Received: from comsys.se (zeta.sys.energyx.se [192.168.0.39]) (authenticated (0 bits)) by localhost.0.168.192.in-addr.arpa (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id h0VAuCCO012953 for ; Fri, 31 Jan 2003 11:56:13 +0100 Message-ID: <3E3A564C.3030909@comsys.se> Date: Fri, 31 Jan 2003 13:36:00 -0000 From: Lars Segerlund User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: GCC 3.3 3.4 ... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg01750.txt.bz2 From following the list I have a humble opinion to express, and that is that perhaps there is a need for more awareness of memory footprint/usage and compiler speed issues. What I am saying is that there might be a rationale for making this a target in future developement/releases. It seem's that there is a lot that can be done in this area, and that the developement so far mostly have focused on code quality and features, ( code quality refers to the generated code here ). However, there seems to be more urgent issues such as regression and new functionality in the backend that are prioritized. Also a review of some of the algorithms used would perhaps be of great value. / regards, Lars Segerlund.