Hi! On 2026-05-16T07:28:37+0000, Paul IANNETTA <[email protected]> wrote: > 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
Thanks for having a look! >> 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 I was assuming that the items discussed in that subthread (started by Georg-Johann Lay) were for "future work" rather than "baseline support", and that all current review items for "baseline support" had gotten addressed in Paul's "v4". In other words: which of these items do we need to address now, before we're able to move forward with the "baseline support" (Paul's "v4", rebased, and to-be slightly polished)? Grüße Thomas > 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. > > - 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
