[Note that emails to <[email protected]> bounce; please use Paul's other email address: <[email protected]>.]
Hi! On 2022-10-12T00:03:04+0200, Paul Iannetta <[email protected]> wrote: > On Mon, Oct 10, 2022 at 03:20:13PM -0400, Jason Merrill wrote: >> On 10/9/22 12:12, Paul Iannetta wrote: >> > That's a nice feature! LLVM is using AS<number> to mangle the >> > address-name qualified types but that would have required an update of >> > libiberty's demangler in the binutils as well. >> >> And they haven't proposed this mangling to >> >> https://github.com/itanium-cxx-abi/cxx-abi/ >> >> yet, either. Hmm, maybe I'm confused (certainly possible; I didn't look into the "named address spaces vs. mangling" topic in any detail yet), but isn't the LLVM mangling what had gotten discuseed already in 2017 <https://github.com/itanium-cxx-abi/cxx-abi/issues/28> "Name mangling for possible new Clang type #28", and gotten resolved via <https://github.com/itanium-cxx-abi/cxx-abi/pull/29> "Record the non-standard mangling of the GNU address_space attribute"? On the other hand, do we need to describe the GNU C++ mangling, once that patch is accepted? Grüße Thomas > When looking at clang/lib/AST/{Microsoft,Itamium}Mangle.cpp, the > comments may suggest that they wanted to implement them as extended > qualifiers prefixed by an `U' but that's not what they ended up doing. > >> You certainly want some template tests, say >> >> template <class T> >> int f (T *p) { return *p; } >> __seg_fs int *a; >> int main() { f(a); } >> // test for mangling of f<__seg_fs int> >> >> ----- >> >> template <class T> >> int f (T __seg_gs *p) { return *p; } >> __seg_fs int *a; >> int main() { f(a); } // error, conflicting address spaces > > Indeed, I was getting the first one right by a stroke of luck but not > the second. I've consequently adapted the part which checks and > computes the unification of cv-qualifiers in the presence of address > spaces. The idea being that a type parameter T can match any address > spaces but an address-space qualified parameter can't accept more > general address spaces than itself. > >> > +/* Return true if between two named address spaces, whether there is a >> > superset >> > + named address space that encompasses both address spaces. If there is >> > a >> > + superset, return which address space is the superset. */ >> > + >> > +bool >> > +addr_space_superset (addr_space_t as1, addr_space_t as2, >> > + addr_space_t * common) >> > +{ >> > + if (as1 == as2) >> > + { >> > + *common = as1; >> > + return true; >> > + } >> > + else if (targetm.addr_space.subset_p (as1, as2)) >> > + { >> > + *common = as2; >> > + return true; >> > + } >> > + else if (targetm.addr_space.subset_p (as2, as1)) >> > + { >> > + *common = as1; >> > + return true; >> > + } >> > + else >> > + return false; >> >> So it's not possible for the two spaces to both be subsets of a third? >> > > According to the [N1275, page 38]: > Address spaces may overlap in a nested fashion. For any two address > spaces, either the address spaces must be disjoint, they must be > equivalent, or one must be a subset of the other. [...] There is no > requirement that named address spaces (intrinsic or otherwise) be > subsets of the generic address space. > [N1275]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf > > Hence, two disjoint address spaces can't be subsets of a third, per > the draft. > >> >> New non-bit-fields should be added before the bit-fields. >> > > Done. > >> > diff --git a/gcc/cp/mangle.cc b/gcc/cp/mangle.cc >> > index eb53e0ebeb4..06625ad9a4b 100644 >> > --- a/gcc/cp/mangle.cc >> > +++ b/gcc/cp/mangle.cc >> > @@ -2509,6 +2509,15 @@ write_CV_qualifiers_for_type (const tree type) >> > array. */ >> > cp_cv_quals quals = TYPE_QUALS (type); >> > + if (DECODE_QUAL_ADDR_SPACE (quals)) >> > + { >> > + addr_space_t as = DECODE_QUAL_ADDR_SPACE (quals); >> >> This can be >> >> if (addr_space_t as = DECODE_QUAL_ADDR_SPACE (quals)) >> >> so you don't need to repeat it. > > I thought this was c++17 only, but in fact c++17 only broadened the > idiom. Nice! (It would be even nicer to have this feature in C as > well) >> > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc >> > index 763df6f479b..110ceafc98b 100644 >> > --- a/gcc/cp/parser.cc >> > +++ b/gcc/cp/parser.cc >> > [...] >> > @@ -23812,6 +23830,13 @@ cp_parser_cv_qualifier_seq_opt (cp_parser* parser) >> > break; >> > } >> > + if (RID_FIRST_ADDR_SPACE <= token->keyword && >> > + token->keyword <= RID_LAST_ADDR_SPACE) >> > + { >> > + cv_qualifier = >> > + ENCODE_QUAL_ADDR_SPACE (token->keyword - RID_FIRST_ADDR_SPACE); >> > + } >> >> We usually omit braces around a single statement. >> > Done.
