Le 05/07/2026 à 23:15, Arsen Arsenović a écrit :
From: Arsen Arsenović <[email protected]>
Hi!
This patch implements the refactor discussed in
https://inbox.sourceware.org/gcc/[email protected]/
for all the frontends and backends.
No functional changes intended.
A few points of note:
1. The C FE could undergo a process of "modernization" to remove the
places where it implements qualifier joins/merges ad-hocly. I
decided to leave this aside for now.
2. I decided to make qualifier_set a struct after all. In most cases,
it should be easy to remove all of the potential overhead that
entails, which is limited to just the 32-bit targets anyway, AFAICT
(it is trivially copyable and destructible, and it is 2 chars long,
so it should be passed by registers on many ABIs).
3. Due to cp_declarator, I had to make qualifier_set trivially
default-constructible (or, alternatively, add a constructor to
cp_declarator). This means it is slightly easier to misuse (because
'qualifier_set foo;' is uninitialized).
4. I didn't remove the Rust copies of expected/optional.h, as that broke
compilation a good bit. Also, the Rust versions use rust_assert, the
new GCC one of course does not. It'd be good to remove the former.
5. I've added a new union operation besides the 'merge' one discussed in
the previous email. Merging two qualifier sets produces a qualifier
set that can be used in place of both. The new operation ended up
being called 'join', and it simply produces a qualifier set
containing the qualifiers of both by simple syntactic concatenation.
6. Making the distinction above also made it quite clear what needs to
be done about the atomic qualifier. For join, it is OK for one QS to
have _Atomic but not the other; for merge, it is not.
The C++ Named Address Space implementation benefited greatly from this
patch (the changes here turned a number of bugs in that patch into
compile errors). I will send it soon (I want to write more
target-independent self-tests for it first).
The reason the CC list is so long is because this patch touches multiple
backends and nearly all frontends. Luckily, most of the changes are
mechanical, so, hopefully it shouldn't be difficult to review.
Reg-strapped on x86_64-linux-gnu, powerpc64le-linux-gnu.
Build-tested for rl78-elf.
Will be regression tested soon for amdgcn-amdhsa and (reg-strapped) for
s390x-ibm-linux-gnu. (these are slower)
OK for trunk? Assuming those tests find no bugs, of course.
OK for the fortran part.
There is one typo in the documentation comment of merge:
+ /* Attempt to produce a qualifier_set that's a merge of qualifiers in THIS
+ and OTHER. Such a qualifier set can be used instead of either THIS or
+ OTHERT safely. (i.e. if a type was qualified by either THIS or OTHER, it
OTHER
+ can be qualified by their merge instead safely, possibly through a
+ conversion)
+
