This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: [Fwd: CVS trunk bootstrap failure on alphaev6-unknown-linux-gnu]
- To: Joern Rennecke <amylaar at redhat dot com>
- Subject: Re: [Fwd: CVS trunk bootstrap failure on alphaev6-unknown-linux-gnu]
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Sat, 07 Jul 2001 14:52:58 +0200
- CC: gcc-bugs at gcc dot gnu dot org
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <200107062132.f66LW5Y07240@phal.cambridge.redhat.com>
Joern Rennecke wrote:
> > This piece of code aborts:
> >
> > /* Generate and return an insn body to add Y to X. */
> >
> > rtx
> > gen_add2_insn (x, y)
> > rtx x, y;
> > {
> > int icode = (int) add_optab->handlers[(int) GET_MODE (x)].insn_code;
> >
> > if (!
> > ((*insn_data[icode].operand[0].predicate)
> > (x, insn_data[icode].operand[0].mode))
> > || ! ((*insn_data[icode].operand[1].predicate)
> > (x, insn_data[icode].operand[1].mode))
> > || ! ((*insn_data[icode].operand[2].predicate)
> > (y, insn_data[icode].operand[2].mode)))
> > abort ();
> >
> > It aborts because it's called with a (const_int 65535 [0xffff]) as y
> > value, which doesn't have a mode.
> Huh? The add?I predicates should allow a CONST_INT when passed their
> respective integer modes. So where does the mode of y come in?
Yep, sorry - shooting from the hip and missed.
On closer examination I think `abort' is called not because y is an
CONST_INT, but because it's a CONST_INT value that cannot be an operand
to an add{s|d}i3 insn on the Alpha (quoting alpha.md):
(define_expand "addsi3"
[(set (match_operand:SI 0 "register_operand" "")
(plus:SI (match_operand:SI 1 "reg_or_0_operand" "")
(match_operand:SI 2 "add_operand" "")))]
...
(define_expand "adddi3"
[(set (match_operand:DI 0 "register_operand" "")
(plus:DI (match_operand:DI 1 "register_operand" "")
(match_operand:DI 2 "add_operand" "")))]
add_operand is defined in alpha.c as:
int
add_operand (op, mode)
register rtx op;
enum machine_mode mode;
{
if (GET_CODE (op) == CONST_INT)
/* Constraints I, J, O and P are covered by K. */
return (CONST_OK_FOR_LETTER_P (INTVAL (op), 'K')
|| CONST_OK_FOR_LETTER_P (INTVAL (op), 'L'));
return register_operand (op, mode);
}
IOW, it's either a constant indicated by `K' or by `L', so (from
alpha.h):
#define CONST_OK_FOR_LETTER_P(VALUE, C) \
((C) == 'I' ? (unsigned HOST_WIDE_INT) (VALUE) < 0x100 \
: (C) == 'J' ? (VALUE) == 0 \
: (C) == 'K' ? (unsigned HOST_WIDE_INT) ((VALUE) + 0x8000) < 0x10000
\
: (C) == 'L' ? (((VALUE) & 0xffff) == 0 \
&& (((VALUE)) >> 31 == -1 || (VALUE) >> 31 == 0)) \
: (C) == 'M' ? zap_mask (VALUE) \
: (C) == 'N' ? (unsigned HOST_WIDE_INT) (~ (VALUE)) < 0x100 \
: (C) == 'O' ? (unsigned HOST_WIDE_INT) (- (VALUE)) < 0x100 \
: (C) == 'P' ? (VALUE) == 1 || (VALUE) == 2 || (VALUE) == 3 \
: 0)
However, "0xffff" fails both the `K' and the `L' check.
The problem, I think, is in that in reload1.c:9220ff you check for an
add insn, but do not have any check for whether the constant to be added
is acceptable for that add insn.
[ Hope I'm correct this time - sorry if not ]
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)