public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "uweigand at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address
Date: Sat, 16 Apr 2005 15:48:00 -0000	[thread overview]
Message-ID: <20050416154835.11512.qmail@sourceware.org> (raw)
In-Reply-To: <20050415081807.21041.matz@suse.de>


------- Additional Comments From uweigand at gcc dot gnu dot org  2005-04-16 15:48 -------
The problem originates in find_reloads_subreg_address, which decides
to widen access to a memory reference.  The instruction we have is:

(insn 129 127 130 10 (parallel [
            (set (reg:SI 106)
                (plus:SI (subreg:SI (reg:QI 104) 0)
                    (subreg:SI (reg:QI 105) 0)))
            (clobber (reg:CC 33 %cc))
        ]) 143 {addsi3} (insn_list:REG_DEP_TRUE 128 (insn_list:REG_DEP_TRUE 127
(nil)))
    (expr_list:REG_DEAD (reg:QI 104)
        (expr_list:REG_DEAD (reg:QI 105)
            (expr_list:REG_UNUSED (reg:CC 33 %cc)
                (nil)))))

and register 104 is equivalent to a memory slot:

(insn 127 128 129 10 (set (reg:QI 104)
        (mem:QI (reg/f:SI 47 [ pretmp.10 ]) [0 S1 A8])) 53 {*movqi}
(insn_list:REG_DEP_TRUE 81 (insn_list:REG_DEP_TRUE 88 (insn_list:REG_DEP_TR
UE 95 (insn_list:REG_DEP_TRUE 102 (insn_list:REG_DEP_TRUE 109
(insn_list:REG_DEP_TRUE 116 (insn_list:REG_DEP_TRUE 123 (nil))))))))
    (expr_list:REG_EQUIV (mem:QI (reg/f:SI 47 [ pretmp.10 ]) [0 S1 A8])
        (nil)))

Now, reg 104 does not get a hard reg assigned. However, register 47 gets
assigned hard reg 0, which is not valid in a memory address.

Because register 104 is now equivalent to an invalid memory reference,
find_reloads_toplev calls find_reloads_subreg_address on the paradoxical
(subreg:SI (reg:QI 104)).

That routine thinks it can replace the subreg with an adjusted equivalent
memory reference (mem:SI (plus (reg 0) (const_int -3))).

It then calls find_reloads_address on that address.  Now, this address
is invalid for *two* reasons: register 0 cannot be used as base register,
and negative displacements are invalid.  find_reloads_address is unable
to cope with this combination, and returns with an address that is still
invalid.

[ If LEGITIMIZE_RELOAD_ADDRESS is active, it fixes the negative displacement
but keeps register 0.  If I disable LEGITIMIZE_RELOAD_ADDRESS, the default
find_reloads_address behaviour will reload register 0, but keep the invalid
displacement. ]

As a workaround, I can add code to LEGITIMIZE_RELOAD_ADDRESS that fixes
both issues and results in a valid address, fixing the ICE.  However, this
has two problems:

1. According to my understanding, L_R_A should never be required for
correctness, but only bring extra performance.  Thus find_reloads_address
alone should also be able to fix the problem.

2. The whole business of widening access to a memory slot is questionable
in this case: if register 47 were to point to the start of a page of memory
preceded by unmapped address space, the widened access would crash.  I had
thought that for this reason, only accesses to *stack slots* can be widened;
scan_paradoxical_subregs would make sure such stack slots are aligned 
properly.  However, in this case just some random memory access is widened.


As a final comment: both test cases in this PR are strictly speaking
invalid C or C++, because uninitialized variables are accessed.  I was
unable to modify the test cases to valid C/C++.  Does the original
unreduced source code also have uninitialized variables?  There have
been some issues in the past where reload would handle uninitialized
pseudos correctly ...

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041


  parent reply	other threads:[~2005-04-16 15:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-15  8:18 [Bug target/21041] New: " matz at suse dot de
2005-04-15  8:19 ` [Bug target/21041] " matz at suse dot de
2005-04-15  8:20 ` matz at suse dot de
2005-04-15 10:21 ` [Bug target/21041] [4.0 Regression] " belyshev at depni dot sinp dot msu dot ru
2005-04-16 15:48 ` uweigand at gcc dot gnu dot org [this message]
2005-06-03 14:56 ` matz at suse dot de
2005-06-06 15:57 ` uweigand at gcc dot gnu dot org
2005-07-06 17:03 ` mmitchel at gcc dot gnu dot org
2005-09-27 16:13 ` mmitchel 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=20050416154835.11512.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).