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]
Other format: [Raw text]

[Bug target/85424] New: The __builtin_packlongdouble function might have issues with the output overlapping the inputs


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85424

            Bug ID: 85424
           Summary: The __builtin_packlongdouble function might have
                    issues with the output overlapping the inputs
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

When I was working on PR target/85075, I noticed the big endian version of the
compiler would not build the 32-bit library that used the function to create an
explicit IBM extended double value.

The problem is the pattern:

(define_insn_and_split "pack<mode>"
  [(set (match_operand:FMOVE128 0 "register_operand" "=d,&d")
        (unspec:FMOVE128
         [(match_operand:<FP128_64> 1 "register_operand" "0,d")
          (match_operand:<FP128_64> 2 "register_operand" "d,d")]
         UNSPEC_PACK_128BIT))]
  "FLOAT128_2REG_P (<MODE>mode)"
  "@
   fmr %L0,%2
   #"
  "&& reload_completed && REGNO (operands[0]) != REGNO (operands[1])"
  [(set (match_dup 3) (match_dup 1))
   (set (match_dup 4) (match_dup 2))]
{
  unsigned dest_hi = REGNO (operands[0]);
  unsigned dest_lo = dest_hi + 1;

  gcc_assert (!IN_RANGE (REGNO (operands[1]), dest_hi, dest_lo));
  gcc_assert (!IN_RANGE (REGNO (operands[2]), dest_hi, dest_lo));

  operands[3] = gen_rtx_REG (<FP128_64>mode, dest_hi);
  operands[4] = gen_rtx_REG (<FP128_64>mode, dest_lo);
}
  [(set_attr "type" "fpsimple,fp")
   (set_attr "length" "4,8")])

Generated an insn not found message, when one of the input operands overlapped
the output.  In the case I saw, operand1 was the same as the second output
register.  It is better to just delete the support for the register overlapping
(and hence trying to save a move), then to see this pop again in somewhat rare
circumstances.

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