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
Johann
- 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
