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

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

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Georg-Johann Lay from comment #15)
> (In reply to Richard Biener from comment #13)
> > The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
> > 
> > https://gcc.gnu.org/g:68d32d02035fc081384ec6d6fd275e49ffa5d016
> > 
> > commit r14-6182-g68d32d02035fc081384ec6d6fd275e49ffa5d016
> > Author: Richard Biener <rguenther@suse.de>
> > Date:   Mon Dec 4 10:35:38 2023 +0100
> > 
> >     middle-end/112830 - avoid gimplifying non-default addr-space assign to
> > memcpy
> >     
> >     The following avoids turning aggregate copy involving non-default
> >     address-spaces to memcpy since that is not prepared for that.
> 
> avr.md cpymemhi currently only accepts const_int sizes.  Does your change
> mean it's not possible (or unsafe) to implement that insn with variable
> sizes for better code?
> 
> The middle end still tries to expand cpymemhi for variable sizes (but
> currently the expander FAILs), so I think I don't understand that part of
> the commit message.

It specifically avoids expanding __builtin_memcpy since that goes off
rails, losing address-space info.  And a user using memcpy () himself
for copying between address-spaces is doing invalid things anyway.

The middle-end should still try to use cpymem and as fallback will emit
a loop IIRC.  Tuning from within the backend should be still possible,
also for variable-size.  It might be the middle-end needs improvements
as well, feel free to open new bugreports with testcases where things
do not work as expected from the middle-end side.