[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

["josh at joshtriplett dot org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850

--- Comment #27 from Josh Triplett <josh at joshtriplett dot org> ---
(In reply to Tom Tromey from comment #21)
> (In reply to Tom Tromey from comment #20)
> 
> > BTW if you want to try it out I have a branch:
> > https://github.com/tromey/gcc/tree/add-sparse-attributes
> 
> This still needs a bit of work.
> I rebased it to be more patchlike and wrote some ChangeLog
> entries, but I still need to verify that all the behavior
> is correct (I forgot a lot of state...) and also write the
> documentation.
> 
> That said, recently I've been wondering whether this could
> be better done as a plugin.  I started down the road of
> simply patching gcc due, I think, to the designated_init
> attribute, which can't really be done as a plugin.
> But it seems that perhaps noderef/force/address_space could
> be; and perhaps also bitwise and nocast.
> 
> In the "pro" column, as a plugin it could be maintained elsewhere.
> That might be interesting.
> 
> In the "con" column, it's a pain if multiple projects want to
> use these checks.  Then it's just one more thing to fetch.
> 
> I'm curious to hear your thoughts on the subject.

Given the goal of providing compatibility with the existing support in Sparse
(and potentially surpassing it in the future with the benefit of better
analysis and compiler infrastructure backing it up), I strongly feel that this
needs to exist in the default distribution of GCC, invokable without any
barriers beyond an additional warning flag.  (And usually not even that;
anything that only emits warnings on code using an extension attribute should
get turned on by default.)

A plugin shipped with GCC and enabled by default could potentially provide that
benefit as well, but that goes against the only "pro" you listed.  I don't
think maintaining this elsewhere makes sense.  Meanwhile, the "con" you listed
seems far more serious.  I'd like to see all projects currently using Sparse
able to transparently take advantage of this.

Please let me know what I can do to help complete this branch.  I'd be happy to
help write the documentation, for instance.