From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9139 invoked by alias); 3 Jul 2014 20:48:35 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 9029 invoked by uid 48); 3 Jul 2014 20:48:28 -0000 From: "josh at joshtriplett dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/59850] Support sparse-style pointer address spaces (type attributes) Date: Thu, 03 Jul 2014 20:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: josh at joshtriplett dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-07/txt/msg00187.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #27 from Josh Triplett --- (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.