This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] potential fix for PR middle-end/7151
- From: "David S. Miller" <davem at redhat dot com>
- To: rth at redhat dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 01 Oct 2002 14:34:05 -0700 (PDT)
- Subject: Re: [RFC] potential fix for PR middle-end/7151
- References: <20020930.213306.100651059.davem@redhat.com><20021001195025.GG12410@redhat.com>
From: Richard Henderson <rth@redhat.com>
Date: Tue, 1 Oct 2002 12:50:25 -0700
On Mon, Sep 30, 2002 at 09:33:06PM -0700, David S. Miller wrote:
> + else if ((in_regnum = true_regnum (in)) >= 0
I didn't think you could use true_regnum this early.
I know it get some of its data from reload itself, and
we're in the middle some place.
At this point, since we are generating reloads, allocate_reg_info()
must have run already to allocate reg_renumber. Unallocated
pseudo register slots in reg_renumber[] will be preinitialized
to -1.
I don't see any problems.
Is this problem related to
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01539.html
Same bug, but his patch assumes SUBREG_REG is a REG, it could
be a MEM. Actually, so does true_regnum() so my patch has
the same bug if it is a bug.
Can we see GET_CODE (SUBREG_REG (x)) == MEM when generating
reloads? Upon further reading, it appears not.
So, if SUBREG_REG can be assumed to be REG here, Jan's patch
is fine and solves my problem too.