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. > 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? 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?) Which other items do we need to address before Paul's patch can be considered? 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
