This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [Fwd: CVS trunk bootstrap failure on alphaev6-unknown-linux-gnu]


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]