This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/67839] New: Bit addressable instructions generated for invalid memory address
- From: "senthil_kumar.selvaraj at atmel dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 04 Oct 2015 13:04:05 +0000
- Subject: [Bug target/67839] New: Bit addressable instructions generated for invalid memory address
- Auto-submitted: auto-generated
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