[PATCH gcc/* 0/2] Typed qualifiers

[Mikael Morin]

Le 05/07/2026 à 23:15, Arsen Arsenović a écrit :
> From: Arsen Arsenović <arsen@gcc.gnu.org>
> 
> Hi!
> 
> This patch implements the refactor discussed in
> https://inbox.sourceware.org/gcc/20260626191622.1785567-1-aarsenovic@baylibre.com/
> 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)
> +