From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29071 invoked by alias); 16 Jun 2004 01:13:37 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 29055 invoked by alias); 16 Jun 2004 01:13:36 -0000 Date: Wed, 16 Jun 2004 01:13:00 -0000 Message-ID: <20040616011336.29053.qmail@sourceware.org> From: "wilson at specifixinc dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040525193213.15653.hjl@lucon.org> References: <20040525193213.15653.hjl@lucon.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/15653] [3.4 Regression]: Gcc 3.4 ICE on valid code X-Bugzilla-Reason: CC X-SW-Source: 2004-06/txt/msg01928.txt.bz2 List-Id: ------- Additional Comments From wilson at specifixinc dot com 2004-06-16 01:13 ------- Subject: Re: [3.4 Regression]: Gcc 3.4 ICE on valid code On Tue, 2004-06-15 at 09:11, vmakarov at redhat dot com wrote: > I'll send a patch for solving this problem too. I don't think we should pay > attention to legacy hardware like itanium1. Could somebody tell me how many > itanium1 machines are used now? And who are using them? I think we should > remove code supporting Itanium1. We can't just drop Itanium1 support. I tried reducing Itanium1 support from binutils. Specifically, I modified binutils to emit the brl (branch long) instruction by default instead of a longer non-brl sequence. This instruction is implemented in hardware in Itanium2, and emulated in software on Itanium1. The ABI requires that brl be emulated, so the only effect on Itanium1 was that some large programs would run a little slower. A few months later, HJ submitted a binutils patch that added an option to emit the non-brl sequence for Itanium1 targets. Obviously, someone still cares about Itanium1 performance, though it is likely a very small number of people. Maybe someone has a large installation of Itanium1 machines that they can't afford to just throw away? For FSF GCC release purposes, I think we can consider Itanium1 specific optimization bugs as less important than general Itanium bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15653