public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "wilson at specifixinc dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/15653] [3.4 Regression]: Gcc 3.4 ICE on valid code
Date: Wed, 16 Jun 2004 01:13:00 -0000	[thread overview]
Message-ID: <20040616011336.29053.qmail@sourceware.org> (raw)
In-Reply-To: <20040525193213.15653.hjl@lucon.org>


------- 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


  parent reply	other threads:[~2004-06-16  1:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-26 14:07 [Bug target/15653] New: " hjl at lucon dot org
2004-05-26 14:15 ` [Bug target/15653] " hjl at lucon dot org
2004-06-01  6:00 ` wilson at gcc dot gnu dot org
2004-06-10 21:06 ` cvs-commit at gcc dot gnu dot org
2004-06-10 21:10 ` cvs-commit at gcc dot gnu dot org
2004-06-10 22:21 ` pinskia at gcc dot gnu dot org
2004-06-11 23:06 ` hjl at lucon dot org
2004-06-11 23:07 ` hjl at lucon dot org
2004-06-12 22:11 ` mmitchel at gcc dot gnu dot org
2004-06-15 16:11 ` vmakarov at redhat dot com
2004-06-16  1:13 ` wilson at specifixinc dot com [this message]
2004-06-16 15:47 ` cvs-commit at gcc dot gnu dot org
2004-06-16 15:51 ` cvs-commit at gcc dot gnu dot org
2004-06-16 19:06 ` pinskia at gcc dot gnu dot org
2004-06-17  7:15 ` wilson at gcc dot gnu dot org
2004-06-21 23:08 ` hjl at lucon dot org
2004-06-21 23:33 ` hjl at lucon dot org
2004-06-21 23:40 ` hjl at lucon dot org
2004-06-22  8:14 ` mmitchel at gcc dot gnu dot org
2004-06-23 22:23 ` wilson at specifixinc dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040616011336.29053.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).