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/67839] New: Bit addressable instructions generated for invalid memory address


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

            Bug ID: 67839
           Summary: Bit addressable instructions generated for invalid
                    memory address
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: senthil_kumar.selvaraj at atmel dot com
  Target Milestone: ---

Bit addressable instructions (sbi, cbi, sbis, sbic) only work on IO addresses
0x0-0x1f (inclusive). The compiler generates these instructions for IO address
0x20 as well.

The problem is in the specification of low_io_address_operand predicate, which
has

(define_special_predicate "low_io_address_operand"                              
  (ior (and (match_code "const_int")
      (match_test "IN_RANGE (INTVAL (op) - avr_arch->sfr_offset,
           0, 0x20 - GET_MODE_SIZE (mode))"))
       (and (match_code "symbol_ref")
      (match_test "SYMBOL_REF_FLAGS (op) & SYMBOL_FLAG_IO_LOW"))))

While this looks ok, gcc invokes low_io_address_operand with mode set to VOID,
and GET_MODE_SIZE for VOID returns 0, so the effective range becomes 0x0-0x20.

gcc does pass the correct mode if the operand mode is set in the define_insn
that uses this predicate. Don't know why it isn't set, and why
define_special_predicate is used instead of define_predicate.

Note that io_address_operand predicate has a GET_MODE_SIZE call as well, so the
range check is off by one in it too


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