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?
(..., 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
