public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hubicka at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/15289] [3.4/3.5 Regression] reload error with non-lowpart subregs
Date: Thu, 26 Aug 2004 12:19:00 -0000 [thread overview]
Message-ID: <20040826121915.15662.qmail@sourceware.org> (raw)
In-Reply-To: <20040505053304.15289.amodra@bigpond.net.au>
------- Additional Comments From hubicka at gcc dot gnu dot org 2004-08-26 12:18 -------
As explained in the cited email, the idea of patch is to avoid silent
misscompilations in the cases similar to those. Here we have single 32bit
register holding 2 8bit fields and we happen to generate SUBREG:QI accessing one
placed in the middle of the word.
i386 has hardware support for this, but I doubt PPC does and we used to simply
pass the subreg around pass reload and forget about the funny byte offset and
finally produe read of the incorrect word.
The particular hunk of code looks quite self explaining - if the subreg can not
be represented by the hardware, we must do something. I can add this comment to
the code if it seems benefical.
Reload is supposed to know how to reload all subregs that are produced earlier,
if he does not, it is either bug to produce one or bug in reload dealing with
this particular case. I will try to look into how the pre 3.4 GCC happent to
deal with this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15289
next prev parent reply other threads:[~2004-08-26 12:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-05 5:33 [Bug target/15289] New: reload error with big-endian subregs amodra at bigpond dot net dot au
2004-05-05 6:30 ` [Bug target/15289] " pinskia at gcc dot gnu dot org
2004-05-05 14:24 ` amodra at bigpond dot net dot au
2004-05-27 21:47 ` [Bug rtl-optimization/15289] reload error with non-lowpart subregs amodra at bigpond dot net dot au
2004-06-16 22:03 ` [Bug rtl-optimization/15289] [3.4/3.5 Regression] " pinskia at gcc dot gnu dot org
2004-08-19 20:53 ` mmitchel at gcc dot gnu dot org
2004-08-26 12:19 ` hubicka at gcc dot gnu dot org [this message]
2004-08-29 19:02 ` mmitchel at gcc dot gnu dot org
2004-10-31 2:08 ` [Bug rtl-optimization/15289] [3.4/4.0 " mmitchel at gcc dot gnu dot org
2004-11-28 13:08 ` steven at gcc dot gnu dot org
2004-11-28 13:27 ` amodra at bigpond dot net dot au
2004-11-28 17:54 ` giovannibajo at libero dot it
2004-11-29 21:25 ` rth at gcc dot gnu dot org
2004-12-01 18:14 ` cvs-commit at gcc dot gnu dot org
2004-12-01 18:16 ` cvs-commit at gcc dot gnu dot org
2004-12-02 19:16 ` cvs-commit at gcc dot gnu dot org
2004-12-03 23:26 ` rth at gcc dot gnu dot org
2004-12-05 5:21 ` cvs-commit at gcc dot gnu dot org
2004-12-05 5:22 ` rth at gcc dot gnu dot org
2004-12-05 5:38 ` pinskia at gcc dot gnu dot org
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=20040826121915.15662.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).