Am 18.05.26 um 20:49 schrieb Thomas Schwinge:
Hi Johann, Jason!
On 2026-05-18T17:05:08+0200, Georg-Johann Lay <[email protected]> wrote:
Am 18.05.26 um 16:19 schrieb Thomas Schwinge:
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?
The example above is for clang that uses
__attribute__((__address_space__(1)))
Sure, I got that -- I was just pointing out that this code isn't
currently applicable to GCC, and I didn't understand what point you're
making with it.
It was just a piece of code to demonstrate avr-clang's AS mangling.
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.
OK, so you're actually suggesting that GCC should mangle '__flash' in the
same way that LLVM/Clang mangles '__attribute__((__address_space__(1)))',
and so on, right?
Hi Thomas,
yes. IMO it is the same feature, though achieved by different means
in clang vs. gcc. avr-gcc's __flash could be achieved in clang with
#define __flash __attribute__((__address_space__(1)))
etc.
This could, I guess, be a GCC target ABI decision (possibly configurable
via a command-line flag?), implemented via a target hook in
'gcc/cp/mangle.cc:write_CV_qualifiers_for_type', to either use Paul's
proposed "actual name" mangling vs. 'AS[N]'? ..., if having the mangling
configurable is desirable for GCC, conceptually? (Jason?)
There are already 3 target hooks for mangling.
Perhaps TARGET_MANGLE_TYPE can already do it.
A command line option for that only makes sense when it is a multilib
option. avr-gcc has already 57 multilibs, and I don't see a benefit
in boosting them by a factor of 2.
Which other items do we need to address before Paul's patch can be
considered?
IMO most important is that it doesn't break C++ code that doesn't
use ASes. Issues with the AS feature (like name mangling) can be
adjusted once the basic patch is upstream. For example, there
should be a means to reject code that writes to an avr AS after
load time, like
int compute_x ();
const __flash int x = compute_x ();
Such code isn't possible in C (when compute_x () is not
computable at load time), but C++ allows it.
Johann
Grüße
Thomas
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
