Am 18.05.26 um 16:19 schrieb Thomas Schwinge:
Hi Johann!
On 2026-05-16T15:30:17+0200, Georg-Johann Lay <[email protected]> wrote:
Am 16.05.26 um 09:28 schrieb Paul IANNETTA:
On Saturday, May 16, 2026 at 12:40:21 AM GMT+9, Jason Merrill
<[email protected]> wrote:
> On 5/15/26 8:17 AM, Thomas Schwinge wrote:
>> 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?)
>
>Looking back, it seems to have been because there was no follow-up after
>my comments in
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606149.html
>
> Jason
Yes, I did not find time to work on the comments that were raised there.
Just a few points I'd like to add:
- Concerning mangling, the patch uses the universal vendor extension,
not the AS<number>.
One of the main reasons was that GCC does not support the definition of
custom
address spaces on the fly with "__attribute__((address_space
(number)))", and always
have a proper name that can be used after the "U" prefix.
Maybe its a good idea to use similar mangling like clang for avr does:
#define AS __attribute__((__address_space__(1)))
void fun (const AS char*)
{
}
compiles to:
_Z3funPU3AS1Kc:
ret
I'm confused, because:
a.C:3:4: warning: ‘address_space’ attribute directive ignored
[-Wattributes]
3 | void fun (const AS char*)
| ^~~~
..., so discussing options for mangling for an 'address_space' attribute
is indeed future work for GCC?
Hallo Thomas,
The example above is for clang that uses
__attribute__((__address_space__(1))), which is equivalent to avr-gcc's
__flash qualifier. This is possible since that attribute (and similar
ones) behave like a qualifier, whereas GCC's attributes don't have the
power of qualifiers, hence GCC cannot use attributes for that.
AFAIK, we have clang's AS(n) behave like avr-gcc's qualifiers:
AS(1) <=> __flash (16-bit flash in 0x0..0xffff)
AS(2) <=> __flash1 (16-bit flash in 0x10000..0x1ffff)
AS(3) <=> __flash2 (16-bit flash in 0x20000..0x2ffff)
etc.
avr-gcc also knows __flashx (24-bit flash address) and __memx (24-bit
linearized flash or RAM address), dunno if clang has equivalents for these.
Johann
(..., and yes, support for that one, and also your suggestion to align
its mangling with pre-existing practice, totally makes sense to me -- but
that's another patch to be written?)
Or, is it that you're suggesting to apply a different mangling scheme for
use of *named address spaces* (which is what Paul's patch adds support
for in GCC), so that GCC produces mangled names as if the first named
address space that gets defined would correspond to
'__attribute__((__address_space__(0)))', and so on?
Grüße
Thomas
- Concerning pointers to class in a specific addresses, the patch does
not enforce anything
and happily compiles things like "myclass __addr_space* var;". However,
I did not dig more
into the consequences.
- You can easily test the current patch and see what happens at the
gimple level by selecting the
KVX port on Goldbolt, you can use "__bypass" and "__speculate" as
"address spaces".
(cf. https://godbolt.org/z/EcqPETEcx )
- Address spaces where used a lot in Kalray's code base, however our C++
code did not exert a lot
of pressure on the C++-only features; that is no heavy use of templates,
neither heavy use of address-space
qualified pointers.
- The part dealing with vtables is yet to address, I'll plan to look
into it if this patch gets merged.
- The target hook "targetm.addr_space.diagnose_usage" is called in
"cp_lexer_get_preprocessor_token"
The out-tree patch is available here [1] (the content is almost the same
as the rebased patch by Thomas),
with some more tests here [2].
Paul
[1]: https://github.com/kalray/gcc/
commit/56fcdd97eeca5a4429869062abdd341bae77ca0d
[2]: https://github.com/kalray/gcc/commit/
cba87c9b2b799923d501863c27a95d04471b8825
