Am 21.05.26 um 16:26 schrieb Paul IANNETTA:
Hi,
On Thursday, May 21, 2026 at 09:19:00 PM GMT+9, Georg-Johann Lay
<[email protected]> wrote:
> Am 15.05.26 um 14:17 schrieb Thomas Schwinge:
> > [Note that emails to <[email protected]> bounce; please use
Paul's
> > other email address: <[email protected]>.]
> >
> > Hi!
> >
> > 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?)
> >
> > I've now rebased this onto recent GCC trunk, see attached
> > '0001-c-parser-Support-for-target-address-spaces-in-C.patch'. There
were
> > just a few merge conflicts that I had to fix up (nothing serious), and
> > I've bootstrap-tested on x86_64-pc-linux-gnu (only, so far).
>
> Hi Thomas,
>
> as far as I can see, there is not a single use of
> TARGET_ADDR_SPACE_FOR_ARTIFICIAL_RODATA resp.
> targetm.addr_space.for_artificial_rodata in the patch.
> There should be a new purpose enum like ARTIFICIAL_RODATA_VTABLE
> when vtables are built. The new enum would be defined in coretypes.h.
>
> The comment in target.def states it is "for optimization purposes only",
> which is no more true for vtables (for vtables it's an ABI thing).
Yes, currently customizing the address space of vtables is not supported.
However, I've not forgotten that part.
Great.
Adding the support for vtable would probably need a few round of reviews,
so if possible I would like to add support for them in a subsequent patch.
> Would you agree?
Paul
I am fine with that. (And I am not in the position to review code btw).
Johann
