Hence, I now believe that your suggested doc change is correct, and is
OK to check in to mainline.
Committed. Thanks!
Index: ChangeLog
===
--- ChangeLog (revision 131702)
+++ ChangeLog (working copy)
@@ -1,6 +1,11 @@
On Thu, 2008-01-10 at 19:16 -0500, DJ Delorie wrote:
IIRC, the bug happened building either libgcc or newlib. If you want
to revert my latest patch in a local source tree and just try a build,
it's likely to show you an example ;-)
It was unwind-dw2.c in the m32cm libgcc multilib.
The
On Wed, 2008-01-09 at 15:38 -0500, DJ Delorie wrote:
[EMAIL PROTECTED] This macro must never return zero, even if a register
+cannot hold the requested mode - indicate that with HARD_REGNO_MODE_OK
+and/or CANNOT_CHANGE_MODE_CLASS instead.
I think that HARD_REGNO_NREGS should not be returning
IIRC, the bug happened building either libgcc or newlib. If you want
to revert my latest patch in a local source tree and just try a build,
it's likely to show you an example ;-)
I would first ask why subreg_get_info is being called with ymode ==
QImode for a hard register which can not hold QImode. That implies
that there is a QImode value in the register, which you say is
invalid.
Are there any ports besides m32c that have registers which can hold HI
(or SI I
DJ Delorie [EMAIL PROTECTED] writes:
I would first ask why subreg_get_info is being called with ymode ==
QImode for a hard register which can not hold QImode. That implies
that there is a QImode value in the register, which you say is
invalid.
Are there any ports besides m32c that
DJ Delorie wrote:
Which assumption is wrong? That hard_regno_nregs can be zero (m32c),
or that hard_regno_nregs will never be zero (rtlanal)?
I would say the m32c port is wrong. HARD_REGNO_MODE_OK indicates
whether a register can hold a mode. HARD_REGNO_NREGS indicates how many
registers
How about this change, then? (I'm still testing the m32c change, too)
2008-01-09 DJ Delorie [EMAIL PROTECTED]
* doc/tm.texi (HARD_REGNO_NREGS): Note that this macro must not
return zero.
Index: doc/tm.texi
===
@defmac HARD_REGNO_NREGS (@var{regno}, @var{mode})
A C expression for the number of consecutive hard registers, starting
at register number @var{regno}, required to hold a value of mode
[EMAIL PROTECTED]
[EMAIL PROTECTED] This macro must never return zero, even if a register
+cannot hold
I find this somewhat unclear - It seems to imply that HARD_REGNO_NREGS may be
called even when HARD_REGNO_MODE_OK returns false.
That's exactly the case that's happening for m32c, and for which the
new text is needed.
In rtlanal.c we have these lines:
nregs_ymode = hard_regno_nregs[xregno][ymode];
...
(GET_MODE_SIZE (ymode) % nregs_ymode) == 0)
The m32c cc1 crashes here because xregno is 1 and ymode is QI, and
register 1 cannot hold a QI value (there are no QImode ops that take
that register), so
11 matches
Mail list logo
