[Bug middle-end/112830] internal compiler error: in convert_memory_address_addr_space_1, at explow.cc:302

["gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #9 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #8)
> Is there a valid testcase that has __memx as the destination?  Or is there
> an address space with similar constraints that allows non-const accesses?

No.  The avr backend throws an error when a non-generic address space thing is
not const, like

__memx int var;

int f1 (__memx int *p)
{
    return *p;
}

foo.c:1:12: error: variable 'var' must be const in order to be put into
read-only section by means of '__memx'
    1 | __memx int var;
      |            ^~~
foo.c:3:21: error: pointer targeting address space '__memx' must be const in
function parameter 'p'
    3 | int f1 (__memx int *p)
      |         ~~~~~~~~~~~~^

__memx covers all address spacec, including generic.  But in order to write one
has to cast it to a generic pointer (after checking that it actually points to
generic and not somewhere else (flash)).

(In reply to Richard Biener from comment #3)
> I think the assert can be relaxed to make truncation OK.

A truncation from 24-bit __memx address to some other AS (all 16 bits) would
require a run-time check which 16-bit AS it encodes, and depending on that
execute code fit for that AS.

This is ok when the user is doing it, but the compiler should never require any
kind of truncation.  And extension / casts are handled by
TARGET_ADDR_SPACE_CONVERT.