Am 18.06.26 um 17:02 schrieb Jason Merrill:
On 6/18/26 5:35 AM, Georg-Johann Lay wrote:
Am 15.05.26 um 15:11 schrieb Paul IANNETTA:
On Friday, May 15, 2026 at 09:17:14 PM GMT+9, Thomas Schwinge
<[email protected]> wrote:
[Note that emails to <[email protected]> bounce; please use Paul's
other email address: <[email protected]>.]
Hi!
I'd like to resume this patch submission here, which is adding support
for named address spaces to GNU C++, as is implemented for GNU C. As far
as I can tell, there wasn't any specific technical reason that this
patch
review stalled, back then, in 2022-11? (Jason?)
I've now rebased this onto recent GCC trunk, see attached
'0001-c-parser-Support-for-target-address-spaces-in-C.patch'. There were
just a few merge conflicts that I had to fix up (nothing serious), and
I've bootstrap-tested on x86_64-pc-linux-gnu (only, so far).
Hi Paul,
I have one test case where the generated code for avr is not correct:
int func1 (int x)
{
static const __flash int arr[] = { 123, 456 };
return arr[x];
}
The code should read from AS1 but reads from generic space.
Sounds like decay_conversion isn't propagating the address space to the
pointer type.
Jason
Here is a related one:
#define AS1 const __flash
extern AS1 int array[] = { 1 };
The object is located in AS0 (.rodata) but should be in the section
for AS1 (.progmem.data). In avr_insert_attributes the node looks fine:
<var_decl 0x7fc286cb8c78 array>
<array_type 0x7fc286caebd0>
<integer_type 0x7fc286cae0a8 int address-space-1> read-only
Simple values like
extern AS1 int value = 1;
are located correctly.
Johann
