On Friday, May 15, 2026 at 09:17:14 PM GMT+9, Thomas Schwinge <[email protected]> wrote:
[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). The 'gcc/targhooks.cc:default_addr_space_subset_p' change that appeared in this v4: bool default_addr_space_subset_p (addr_space_t subset, addr_space_t superset) { - return (subset == superset); + return (subset == 2 && superset == 0) || (subset == superset); } ... is entirely unmotivated, as far as I can tell: probably a local hack for testing, that sneaked into the patch posted? This change regresses 'gcc.target/i386/addr-space-typeck-1.c' (notice: C test case), which again PASSes with that change undone. The new test case 'g++.dg/template/spec-addr-space.C' needs minor adjusting per changed GCC diagnostics (not related to the new named addess space support): @@ -1,8 +1,9 @@ // { dg-do compile { target { i?86-*-* x86_64-*-* } } } template <class T> -int f (T __seg_gs *p) { return *p; } // { dg-note "candidate: 'template<class T> int f.__seg_gs T\*." } +int f (T __seg_gs *p) { return *p; } // { dg-note "candidate 1: 'template<class T> int f.__seg_gs T\*." } // { dg-note "template argument deduction/substitution failed:" "" { target *-*-* } .-1 } __seg_fs int *a; int main() { f(a); } // { dg-error "no matching" } -// { dg-note "types .__seg_gs T. and .__seg_fs int. have incompatible cv-qualifiers" "" { target *-*-* } .-1 } +// { dg-note "there is 1 candidate" "" { target *-*-* } .-1 } +// { dg-note "types .__seg_gs T. and .__seg_fs int. have incompatible cv-qualifiers" "" { target *-*-* } .-2 } With that, all new test cases PASS, and no regressions. If we get a general "go", I'll then offer to fix up a few places for GCC coding style conformance (so please don't review for that, yet), and I'll work on test cases some more. I'll also examine if, since then, any new code has appeared where 'ADDR_SPACE_CONVERT_EXPR' needs to be handled. PR69549 "Named Address Spaces does not compile in C++" is going to be resolved by this patch, so should get referenced in the Git log. Full-quote of Paul's email from back then: On 2022-11-10T16:42:22+0100, Paul Iannetta <[email protected]> wrote: > Hi, > > It took a bit of time to rework the rough corners. I tried to be > mirror as much as possible the C front-end, especially when it comes > to implicit conversions, and warnings; and expose the same hooks as > the C front-end does. The C++ front-end produces as much warnings > that the C front-end, however they are sometimes a bit less > informative (especially so, when passing arguments to functions). > > I also address the following points: > > 1. The handling of the register storage class is grouped with the > other variables with automatic storage. This incurs a slight > dis-alignment since you cannot have global register variables do not > trigger an error, only a warning. > > 2. In template unification, I maintain that we don't want any > changes to address spaces whatsoever during the unification process, > hence ignoring the strict flag. Nevertheless, we allow implicit > conversion, and I have verified that, indeed, > > > template <class T> void f(T **); > struct A { > template <class T> operator T*__seg_fs*(); > }; > int main() > { > f((void* __seg_fs *)0); // (1): void*__seg_fs* -> void** should be OK > void (*p)(void * __seg_fs *) = f; // (2): error > } > > works as intended. That is, (1) works if we set __seg_fs as a subspace > of the generic address space, and (2) is always an error. > > 3. In template unification, when unifying __as1 T = __as2 U we want > to unify to the __as1 at most, never to __as2 at most, because the > function requiring __as1 T may want to mix address space from the > bigger address space, therefore I think that we want to have the > smaller address-space to be unified into the bigger of the two. > > 4. I left untouched same_type_ignoring_top_level_qualifiers_p, even > though that was very convenient and often lead to better error > messages since error were caught earlier. > > 5. The handling of conversions is done very late in the calling > chain, because I absolutely want to fold the conversion and force > the conversion to appear as an ADDR_SPACE_CONV_EXPR after > gimplification. > > 6. Currently, I do not handle classes. I see what I can do in a > further revision and maybe add a target hook to hand down to targets > the choice of the address space of the vtable. > > 7. This can't be added as a test case, but I checked that: > > // In this test case, __seg_gs is a subset of the generic address > // space. > > int f (int *); > int main () > { > int __seg_fs *pa; > int __seg_gs *pb; > int *pc; > pa = (__seg_fs int *) pb; return *pa; // warning: cast to ‘__seg_fs’ address > space pointer from disjoint ‘__seg_gs’ address space pointer > pa = (int __seg_fs *) pc; return *pa; // warning: cast to ‘__seg_fs’ address > space pointer from disjoint generic address space pointer > pa = pb; return *pa; // error: invalid conversion from ‘__seg_gs int*’ to > ‘__seg_fs int*’ > pc = pb; return *pc; // __seg_gs int * -> int * converted through > ADDR_SPACE_CONV_EXPR > pb = pc; return *pb; // error: invalid conversion from ‘int*’ to ‘__seg_gs > int*’ > pc = pa; return *pb; // error: invalid conversion from ‘__seg_fs int*’ to > ‘int*’ > return f (pb); // __seg_gs int * -> int * converted through > ADDR_SPACE_CONV_EXPR > // return f (pa); // error: invalid conversion from ‘__seg_fs int*’ to ‘int*’ > // note: initializing argument 1 of ‘int f(int*)’ > } > > Thanks, > Paul > > Rebased on current trunk, bootstrapped and regtested. Hi, Thank you for taking the time to rebase this patch on trunk. I've compared your rebased patch to my local version and I did not spot any significant differences. Concerning, 'gcc/targhooks.cc:default_addr_space_subset_p', I confirm. This is a spurious change, and it does not appear in my local tree. Paul
