Arsen Arsenović <[email protected]> writes: > [[PGP Signed Part:Good signature from 52C294301EA2C493 Arsen Arsenović > (Gentoo Developer UID) <[email protected]> (trust ultimate) created at > 2026-06-20T13:10:08+0200 using EDDSA]] > Georg-Johann Lay <[email protected]> writes: > >> 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, I found one more problem on avr: >> >> #define AS1 const __flash >> #define AS8 const __memx >> >> typedef int (* AS1 fun_t)(); >> >> int foo (AS8 fun_t *f) >> { >> return (*f) (); >> } >> >> Compiling for C, I am getting a parm_decl like this: >> >> <parm_decl 0x7fb7668d3000 f> >> <pointer_type 0x7fb7668a77e0> >> <pointer_type 0x7fb7668a7690 fun_t address-space-8> read-only >> <function_type 0x7fb766782690> >> <integer_type 0x7fb76676f5e8 int> return >> <void_type 0x7fb7667771f8 void> >> >> and an error message: >> >> x.c:6:21: error: conflicting named address spaces (__memx vs __flash) >> 6 | int foo (AS8 fun_t *f) >> >> With C++ there is AS9 even though the source says AS8: >> >> <parm_decl 0x7ff87a763088 f> >> <pointer_type 0x7ff87a74cbd0> >> <pointer_type 0x7ff87a74ce70 fun_t address-space-9> read-only >> <function_type 0x7ff87a619930> >> <integer_type 0x7ff87a6055e8 int> return >> <void_type 0x7ff87a60e1f8 void> >> >> and then ICEs as there is no name for AS9: >> >> x.c:6:5: internal compiler error: in c_addr_space_name, at >> c-family/c-common.cc:659 >> 6 | int foo (AS8 fun_t *f) >> | ^~~ >> >> Johann > > Thanks, noted. I can reproduce the lack of diagnostic on GCN in my > version of the patch (still not quite done..); will fix before > sending.
Thanks again. Done:
(gdb) ! cat conflict-johann.cc
#define AS1 const __flat
#define AS2 const __scalar_flat
typedef int (* AS1 fun_t)();
int foo (AS2 fun_t *f)
{
return (*f) ();
}
(gdb) r conflict-johann.cc
Starting program:
/srv/data/aarsenovic/amdgcn-amdhsa/obj/gcc-mainline-0-amdgcn-amdhsa-x86_64-linux-gnu/gcc/cc1plus
conflict-johann.cc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
conflict-johann.cc:2:19: error: conflicting named address spaces (__flat vs
__scalar_flat)
2 | #define AS2 const __scalar_flat
| ^~~~~~~~~~~~~
conflict-johann.cc:6:10: note: in expansion of macro 'AS2'
6 | int foo (AS2 fun_t *f)
| ^~~
(note that I had to port the testcase to GCN, but it is otherwise
identical)
> The AS9 is obviously a result of doing 'quals | ENCODE_QUAL_ADDR_SPACE
> (...)' somewhere.
>
> I wish we didn't store qualifiers as just a packed integer value, so
> that errors like this could be caught by the type system.
Indeed, it was this one, in decl.cc:grokdeclarator:
type_quals |= cp_type_quals (type);
type = cp_build_qualified_type
(type, type_quals, ((((typedef_decl && !DECL_ARTIFICIAL (typedef_decl))
|| declspecs->decltype_p)
? tf_ignore_bad_quals : 0) | tf_warning_or_error));
/* We might have ignored or rejected some of the qualifiers. */
type_quals = cp_type_quals (type);
:/ 'int' is a convenient shorthand for a set, but it starts being a big
issue when the set ceases to be a simple set, as is the case with the
introduction of address spaces. And it is non-trivial to analyze all
uses of this set-like semantic, as the 'int' type carries very little
semantic weight and is ergo used everywhere.
We should perhaps replace it with some trivially-copyable struct. That
should be just as easy to carry while preventing such errors.
--
Arsen Arsenović
signature.asc
Description: PGP signature
