On 8/21/26 8:19 PM, Arsen Arsenović wrote:
Jason Merrill <[email protected]> writes:
On 8/21/26 7:56 AM, Arsen Arsenović wrote:
Here's a version with those changes made. (I'm yet to remove Syd's
expected/optional)
It looks like nothing in this patch seems to use the merge/join functions that
rely on tl::expected, so maybe we could defer those functions for now?
It would not be much of a deference, since already in the C++ named
address spaces implementation, they are used.
Arguably, the C FE /should/ be made to use these immediately, but I
didn't prioritize that initially.
The backport seems not to be too difficult anyway.
But, I've just realized something that may be a slight issue (but maybe
it's immaterial): the union between two instances of cv_qualifier is not
always necessarily a total function either.
For what is called 'join' on qualifier sets, i.e. a syntactic union, it
is a complete function (unlike for qualifier sets), and coincides with
the bit-OR operator fine.
But, for what's called 'merge' on qualifier sets, i.e. creating a
new qualifier set such that it is compatible with both input qualifier
sets, it is not:
~$ gcc -x c - -fsyntax-only <<<'void foo(_Atomic int *x, int *y) { 1/(y ?
x : y); }'
<stdin>: In function ‘foo’:
<stdin>:1:45: error: pointer type mismatch in conditional expression
[-Wincompatible-pointer-types]
<stdin>:1:43: note: first expression has type ‘_Atomic int *’
<stdin>:1:47: note: second expression has type ‘int *’
I say this may be immaterial because C++ (and other non-C languages) do
not have _Atomic qualification at all, so it is a total function in
those, and C would (ideally, eventually) use qualifier_set directly
always.
This could be addressed by deleting operator| on cv_qualifier and
providing cv_merge/cv_join perhaps, but given the above I'm not sure
it's worth it.
Yeah, I think it's fine; if the result of | isn't usable, we should get a
suitable diagnostic.
If operator| was to be deleted, then the C FE would probably need to
undergo a conversion into using join/merge also. I am not sure at the
moment what the effect on the other FEs would be, but I imagine it would
be notable.
I meant that if | gives us a set that won't work for conversions, we
will get a conversion error, so we don't need to also check the | operation.
Given that most FEs don't deal with the _Atomic qualifier, it may make
sense to make cv_qualifier only refer to access qualifiers, and thus
move _Atomic into qualifier_set.
But, then, the Ada FE *does* use _Atomic, but not address spaces, so
it'd make sense to make some tier between the two to accommodate for
that. (But, that could perhaps be made Ada-specific; ada_type_quals
would just have to return some Ada-specific qualifier set type that
includes _Atomic but not address space qualification. Ada has no use
for the merge and join operations anyway AFAICT so that may be quite
easy).
Luckily, no other FE seems to contemplate TYPE_QUAL_ATOMIC or
TYPE_ATOMIC, so that path may even be viable.
This seems like a possible future direction, not necessary now.
Jason
