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.
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.
--
Arsen Arsenović
signature.asc
Description: PGP signature
