https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112830
Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |avr
Keywords| |addr-space,
| |ice-on-valid-code
--- Comment #1 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
In explow.cc, we have:
rtx convert_memory_address_addr_space_1 (...)
{
#ifndef POINTERS_EXTEND_UNSIGNED
gcc_assert (GET_MODE (x) == to_mode || GET_MODE (x) == VOIDmode); // line 302
return x;
#else /* defined(POINTERS_EXTEND_UNSIGNED) */
so it seems the backend has to define POINTERS_EXTEND_UNSIGNED, which it
currently doesn't. However, the documentation of PEU reads:
> Macro: POINTERS_EXTEND_UNSIGNED
> A C expression that determines how pointers should be extended from
> ptr_mode to either Pmode or word_mode. It is greater than zero if
> pointers should be zero-extended, zero if they should be sign-extended,
> and negative if some other sort of conversion is needed. In the last case,
> the extension is done by the target’s ptr_extend instruction.
> You need not define this macro if the ptr_mode, Pmode and word_mode are
> all the same width.
The avr backend has:
Pmode = word_mode = HImode (16 bits), mode for ADDR_SPACE_GENERIC
PSImode = 24 bits, mode for ADDR_SPACE_MEMX, aka. __memx
So it appear the middle-end wants to "extend" a pointer from 24-bit PSImode to
16-bit Pmode, which makes no sense. Apart from that, the code does not require
any pointer adjustments.
One guess is that the middle-end tries to expand the memcpy, because insn
cpymemhi only support CONST_INT lengths, and gets somethig wrong about address
spaces.
The backend defines TARGET_ADDR_SPACE_CONVERT, and
TARGET_ADDR_SPACE_ADDRESS_MODE is the same like TARGET_ADDR_SPACE_POINTER_MODE
for all address spaces.
